Господа, не флейма ради совершенно!

Большая просьба накидать ссылок на всевозможные обсуждения-выводы-исследования по сабжевому вопросу (в смысле какой способ хранения информации в каких случаях более подходит, за-против и т.п.).

Database имеется в виду в первую очередь традиционный реляционный; но и про всякие объектно-ориентированные тоже интересно.

Если у кого-то есть свои мысли поделиться — тоже интересно; но в первую очередь — "уже готовое".

Спасибо.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Если у кого-то есть свои мысли поделиться — тоже интересно; но в первую очередь — "уже готовое".

Готового не видел. Но вопрос вобщем то не такой уж и сложный — практически всегда выгоднее БД. ФС не поддерживает произвольные индексы и плохо себя чувствует при большом количестве элементов. Единственное преимущество ФС — проще деплоймент, но и это преимущество при наличии встраиваемых БД под вопросом.

AndrewVK wrote:
> Готового не видел. Но вопрос вобщем то не такой уж и сложный —
> практически всегда выгоднее БД. ФС не поддерживает произвольные индексы
> и плохо себя чувствует при большом количестве элементов. Единственное
> преимущество ФС — проще деплоймент, но и это преимущество при наличии
> встраиваемых БД под вопросом.
Еще FS очень хорошо работает с кусками бинарных данных. Покажите мне как
сделать memory mapped file в БД.

Здравствуйте, Cyberax, Вы писали:

C>Еще FS очень хорошо работает с кусками бинарных данных. Покажите мне как
C>сделать memory mapped file в БД.

А зачем? MMF это уже конкретное решение, а не задача.

AndrewVK wrote:
> C>Еще FS очень хорошо работает с кусками бинарных данных. Покажите мне как
> C>сделать memory mapped file в БД.
> А зачем? MMF это уже конкретное решение, а не задача.
Тем не менее, это один из самых быстрых и удобных методов работы с
файлами. С БД такое уже не проходит.

Здравствуйте, Cyberax, Вы писали:

C>Тем не менее, это один из самых быстрых и удобных методов работы с
C>файлами.

Вот именно что с файлами. А спрашивали про средство работы с данными вобще.

C> С БД такое уже не проходит.

Естественно, потому что совсем иная идеология.

AndrewVK wrote:
> C>Тем не менее, это один из самых быстрых и удобных методов работы с
> C>файлами.
> Вот именно что с файлами. А спрашивали про средство работы с данными вобще.
Для средств работы с "данными вообще" идеально подходит сферическая БД в
вакууме.

> C> С БД такое уже не проходит.
> Естественно, потому что совсем иная идеология.
Вот, а изначальный вопрос был как раз про это — чем БД и плоские файлы
отличаются (см. subj).

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Господа, не флейма ради совершенно!

ЗХ>Большая просьба накидать ссылок на всевозможные обсуждения-выводы-исследования по сабжевому вопросу (в смысле какой способ хранения информации в каких случаях более подходит, за-против и т.п.).

ЗХ>Database имеется в виду в первую очередь традиционный реляционный; но и про всякие объектно-ориентированные тоже интересно.

ЗХ>Если у кого-то есть свои мысли поделиться — тоже интересно; но в первую очередь — "уже готовое".

ЗХ>Спасибо.

рекомендую sql.ru
к сожалению там не такой удобный поиск как здесь, но при наличии желания можно набрести на интересные обсуждения с участием весьма опытных спецов по этой теме.

Что до моего мнения, то ответ зависит от характера данных. Если данные слабо структуррованы, не типизированные, бинарно-потоковые, склонны менять свой размер, то файловая система лучше, ибо заточена под это. Если же речь идет о хорошо структуриованных данных (с четко выраженной повторяемостью структуры), то БД рулит адназначна

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Большая просьба накидать ссылок на всевозможные обсуждения-выводы-исследования по сабжевому вопросу (в смысле какой способ хранения информации в каких случаях более подходит, за-против и т.п.).

ЗХ>Database имеется в виду в первую очередь традиционный реляционный; но и про всякие объектно-ориентированные тоже интересно.

ЗХ>Если у кого-то есть свои мысли поделиться — тоже интересно; но в первую очередь — "уже готовое".

Не понятна цель такого сравнения. Без конкретной постановки задачи это все равно, что сравнивать китайскую и французкие кухни -- у китайцев, французов или, скажем, у русских, на этот вопрос будут разные точки зрения.

Хотя, если для какого-то обзора это нужно, то можно взять какую-нибудь книгу по СУБД, посмотреть во введение. Все качества, которые обеспечивают СУБД (транзакционность, восстанавливаемость, многопользовательность, поддержка ad-hoc запросов, администрирование, распределенность и т.д.) можно заносить в актив СУБД в большинстве случаев. В остальных случаях -- в пассив

Но тут еще один момент. Если какое-то решение над файлами (не СУБД) начинает предоставлять некоторые качества СУБД (транзакционность или поддержку конкурентного доступа), то такое решение уже нельзя считать простым использованием файлов, скорее системы хранения, но не СУБД.

Если речь идет о выборе какого-то технического решения для конкретной задачи, то без условий задачи что-либо толковое сказать невозможно.

Здравствуйте, vdimas, Вы писали:

V>рекомендую sql.ru
Надеюсь, хоть не форум сравнения СУБД?

V> с участием весьма опытных спецов по этой теме.
По теме работы с ФС и сравнения этого дела с БД? Это вряд ли. Ну ладно, я пожалуй соглашусь, что там можно найти несколько человек хорошо разбирающихся в конкретной БД, но откопать их среди орды горлопанов — задача не тривиальная..
Ничего личного, мне просто sql.ru не нравится..

V>Что до моего мнения, то ответ зависит от характера данных. Если данные слабо структуррованы, не типизированные, бинарно-потоковые, склонны менять свой размер, то файловая система лучше, ибо заточена под это. Если же речь идет о хорошо структуриованных данных (с четко выраженной повторяемостью структуры), то БД рулит адназначна
Тут важн не сколько характер данных, сколько методы работы с этими данными. Скажем, реализовывать самому эффективный параллельный доступ — вспотеешь, да еще пол-москвы в лютый мороз обогревать сможешь, если возьмешся за это в серьез, а в БД всё это уже реализовали неглупые дядьки на протяжении десятка лет. И это если не вспоминать про оптимизацию запросов и все остальное.
А больше в отрыве от задачи и не скажешь.

Merle wrote:
> Тут важн не сколько характер данных, сколько методы работы с этими
> данными. Скажем, реализовывать самому эффективный параллельный доступ —
> вспотеешь, да еще пол-москвы в лютый мороз обогревать сможешь, если
> возьмешся за это в серьез, а в БД всё это уже реализовали неглупые
> дядьки на протяжении десятка лет. И это если не вспоминать про
> оптимизацию запросов и все остальное.
С другой стороны, организовать в БД доступ к нструктурированым (с точки
зрения БД) бинарным данным — получается плохо. Блобы работают в разы
медленнее файлов в FS и не поддерживают MM.

Здравствуйте, eao197, Вы писали:

E>Хотя, если для какого-то обзора это нужно, то можно взять какую-нибудь книгу по СУБД, посмотреть во введение. Все качества, которые обеспечивают СУБД (транзакционность, восстанавливаемость, многопользовательность, поддержка ad-hoc запросов, администрирование, распределенность и т.д.) можно
заносить в актив СУБД в большинстве случаев. В остальных случаях -- в пассив

Это и ФС умеют, хотя сочетания всех этих качеств сейчас, может, и не найти, такая ФС не за горами.

Здравствуйте, Merle, Вы писали:

M>Тут важн не сколько характер данных, сколько методы работы с этими данными. Скажем, реализовывать самому эффективный параллельный доступ — вспотеешь, да еще пол-москвы в лютый мороз обогревать сможешь, если возьмешся за это в серьез, а в БД всё это уже реализовали неглупые дядьки на протяжении десятка лет. И это если не вспоминать про оптимизацию запросов и все остальное.
M>А больше в отрыве от задачи и не скажешь.

Паралелльный доступ в ФС реализован по определению + эффективное кеширование данных и ограничение доступа к объектам ФС. Вообще, различие между ФС и БД постепенно стирается. В ReiserFS уже можно легко хранить кучи мелких объектов, доступ к которым будет быстрым.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Большая просьба накидать ссылок на всевозможные обсуждения-выводы-исследования по сабжевому вопросу (в смысле какой способ хранения информации в каких случаях более подходит, за-против и т.п.).

Дык зависит от задачи. И терминалогии. Напиример, исходники в БД хранить явно неразумно. Тут лучше подойдут файлы и сорс-контрол. А финансовую информацию логично хранить в БД, так как ее при этом проще анализировать.

Общее правилао будет наверно таким:

Если данные целиком загружаются в память или читаются только последовательно, то БД не нужна. В обратном случае БД предпочтительна.

Хотя опять же под словом БД можно понимать много чего. Например, тот же сорс-контрол или какой-нибудь DataSet, так как он позволяет индексировать данные и делать запросы. В этом случае получить однозначный овтет на вопрос вообще не представляется возможным.

Здравствуйте, Quintanar, Вы писали:

Q>Паралелльный доступ в ФС реализован по определению
С разруливанием конфликтов доступа и изоляции транзакций? Ага... (здесь я имею ввиду не транзакции ФС, а прикладные транзакции)

Q>+ эффективное кеширование данных и ограничение доступа к объектам ФС.
В БД кеширование существенно эффективнее, потому как ближе к контексту, то же самое и с ограничением доступа.

Q> Вообще, различие между ФС и БД постепенно стирается.
Стирается конечно. И ее стирают изовсех сил, достаточно WinFS вспомнить, которая уже больше БД, чем ФС, но за счет того, что ФС приближается к БД, а не наоборот. Проблема в том, что при текущем положении дел ФС гораздо более низкоуровневая конструкция, чем БД.
БД — это компромис, между совсем абстрактными данными, не поддающимися никакому формализму, и совершенно конкретными данными, которыми можно оперировать только зная предметную область к которой относятся эти данные.
Иными словами, БД говорит, что если ваши данные удовлетворяют таким-то требованиям (e.g. реляционны), то у этих данных для нас реализована: атомарность, согласованность, изолированность, сохраняемость, эффективный доступ по предикату, ect... И для того чтобы грамотно реализовать для конкретного приложания в рамках ФС, все что предоставляет БД надо угрохать кучу сил с вполне предсказуемым эффектом. Так что когда стоит вопрос выбора между ФС и БД, то это, на самом деле, вопрос — нужно ли для данного приложения всё то богатство возможностей, что предоставляет БД, или нет. И если нужно, то ответ очевиден.

Здравствуйте, Quintanar, Вы писали:

Q>Это и ФС умеют, хотя сочетания всех этих качеств сейчас, может, и не найти, такая ФС не за горами.
Ты забываешь тот факт, что ФС работает на гораздо более низком уровне и не предоставляет прикладному коду подходящих абстракций, для того чтобы тот мог пользоваться этим в своих, сугубо утилитарных целях.
Что толку от того, что NTFS уже с десяток лет удовлетворяет требованиям ACID, когда для того чтобы ACID-ной была бизнес-транзакция поверх NTFS, все равно все приходится разруливать самому.

Здравствуйте, Cyberax, Вы писали:

C>С другой стороны, организовать в БД доступ к нструктурированым (с точки
C>зрения БД) бинарным данным — получается плохо.
Или получается плохо объяснить БД, что эти данные на самом деле структурированы...

C>Блобы работают в разы медленнее файлов в FS
Смотря что с этими блобами делать, чтобы в разу получить, надо очень напрячься, лучше с помощником.

C> и не поддерживают MM.
Вот дались тебе эти ММ, тебеже уже дважды сказали, что ММ это конкретный способ работы с ФС, у БД есть свои конкретные способы для своих конкретных задач. Дело в задаче, а не в том как ты ее будешь решать.

Здравствуйте, Merle, Вы писали:

M>По теме работы с ФС и сравнения этого дела с БД? Это вряд ли. Ну ладно, я пожалуй соглашусь, что там можно найти несколько человек хорошо разбирающихся в конкретной БД, но откопать их среди орды горлопанов — задача не тривиальная..
M>Ничего личного, мне просто sql.ru не нравится..

Не зазнавайся.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Если у кого-то есть свои мысли поделиться — тоже интересно; но в первую очередь — "уже готовое".

Если речь не идёт о паре небольших конфигурационных XML файлов, то подобный вопрос вообще не должне стоять. Можно ещё было бы говорить о Database+Filesystem vs. Database, но сабж, для приложений интенсивно работающих с данными вряд ли имеент смысл. Всё равно придёшь к файлам, которые будут выполнять роль и функции БД, только значительно хуже.

К тому же файловая система имеет весьма существенное ограничение по количеству файлов в одном каталоге. Помнится даже пару лет назад RSDN фактически был выведен из строя на неделю из-за подобной проблемы.

Здравствуйте, Зверёк Харьковский, Вы писали:

или про что? Что конкретно имеется ввиду?

ЗХ>Если у кого-то есть свои мысли поделиться — тоже интересно; но в первую очередь — "уже готовое".

База данных это такой файл (или группа файлов).
А файл это множество секторов на диске.
А множество файлов это файловая система.
А фаловая система это такая база данных.
А база данных это такой файл...