В комментариях безумцы!

[metaclass]

[...]

Человек спрашивает, как правильно раздавать с СУБД связанные с ней внешние файлы (есть такой метод - вместо блобов держать файлы рядом на сервере, а в базу писать путь к ним). Речь идет об Interbase и приложении на дельфи.
Чего там только не насоветовали:

1) Купить 1С:Архив
2) Изучать CMS
3) Хранить базу в LDAP и файлы тоже в LDAP
4) Отдавать документы по HTTP с помощью mod_rewrite

Единственный более-менее имеющий отношение к делу комментарий - первый - хранить файлы в блобах. Все остальное - боб с горохом, ад, израиль, ханука и дивизия СС на via dolorosa.

К вопросу о том, что всякое ИТ настолько безумная область, что до сих пор на каждую задачу можно найти 100 способов решения, из которых 90 будут неприменимы для данного конкретного случая, а оставшиеся 10 настолько дорогими и безумными, что проще придумать 101 способ, чем осознать существующие.

Comments

[themech.livejournal.com]

последний абзац - цитата дня, однозначно!

[1ceheart.livejournal.com]

Про LDAP хорошо :)

[veter-r-r.livejournal.com]

Хм.. как говорила та эстонская девушка "Вопрос понятен, а в чем проблема?"
В смысле, зачем вся эта петрушка с блобами и прочими мерзостями?

[metaclass.livejournal.com]

Хранить внешние документы с привязкой к базе. Например вордовский файл или еще какую холеру.
Я, например, так звук и текст храню в системе для распознавания надиктованных документов. Чтобы не нужно было тащить за собой 10 гиг хранилища, если нужно на базу данных взглянуть :)

[veter-r-r.livejournal.com]

А тащить за собой 10 гиг базы это кошернее??

[eu3eu.livejournal.com]

+1! :)

[vp.livejournal.com]

ничего не +1
любой другой способ порождает чудовищ в виде двойного протоола доступа к хранилищу. Например, клиент сосет базу по ТСР, а тут параллельно еще для файлов ему будет нужен SMB по виндовой сети, со всеми жуками, жаба и змеями от СМБ, типа непрохождению бродкастов через шлюзы и т.п. мерзости. Фу-фу. Потому все-таки правильнее делать единообразный протокол, один единственный. Пофиг на размеры базы и т.п.

[metaclass.livejournal.com]

Так я про это и говорю.
Вариант "хранить все в базе" привлекательней с точки зрения единообразности доступа и назначения прав, но геморроя тянет за собой немеряно.

[samurai-within.livejournal.com]

/me как-то слабо верит в адекватность работы базенки с гигами блобов. Все конечно от задачи зависит.. но скорость имхо будет падать сииильно.

[metaclass.livejournal.com]

Interbase вроде внутри хранит для каждой таблицы дерево страниц, на которых она лежит. А блобы лежат или внутри записей, если помещаются на страницу или на отдельных страницах, а из записей на них ведут указатели. И все это с транзакциями, версионностью, сборкой мусора и прочей добротой.
Просто работа с базой(фильтрация записей, итд) замедлится не сильно, сервер все равно будет читать только нужные страницы, а вот работа с блобами вместо файлов - прилично, ибо возникнет промежуточный слой между файловой системой и клиентом, фактически реализующий те же функции файловой системы, только внутри файла базы.

[az-from-belarus.livejournal.com]

Добавьте сюда еще и однозначный перекос в сторону тяжелого сервера и концентрации функционала в одной системе. Т.е. о возможности работы с файлами в контекстах разных ситем и приложений можно забыть. Жестко. Иногда - оправдано. Но могут быть и варианты, когда уже есть файловые хранилища сформированные по своей РАБОТАЮЩЕЙ логике и укладка их в централизованные блобы может повлечь большое количество непредвиденного и длительного гемора. Ну и, конечно, ситуация со множеством файловых хранилищ удаленных друг от друга структурных подразделений.

[pete-by.livejournal.com]

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

Cons:
1. Сложности с транзакциями
2. Усложнение механизма репликации

Pros:
1. Апач отдает файлы быстрее, чем реляционная БД
2. Проще прикрутить скажем индексацию документов и полнотекстовый поиск по не plain-text документам вроде DOC.

Если хранить в базе, а не на диске:

Cons:
1. Сильно возрастает нагрузка на базу, возрастает длительность транзакции, при прочих равных уменьшается кол-во конкурентных пользователей, которых теняет система.
2. Усложнение поиска по документам, т.к. придется скорее всего писать собственный механизм индексирования (или покупать).
3. При большом количестве документов придется делать распределенную базу и настраивать балансировку нагрузки, имхо на уровне http-сервера сделать это проще.

Pros:
1. Транзакционность
2. Тривиальная репликация

Это из того, что сразу приходит в голову, наверняка есть еще что-то.

[ennor.livejournal.com]

За все платформы не скажу, но для связки Win+MSSQL вопрос "BLOB vs. FS" уже давно стал исключительно религиозным. Есть куча различных аспектов, влияющих как на производительность, так и на расширяемость в обеих архитектурах - если их все учесть, то для каждого конкретного случая можно построить оптимальную систему.

А когда все это пишется на коленке доморощенными спецами, которые случайно где-то выучили SELECT * FROM ALL_TABLES и сочли, что для работы с базой им этого будет достаточно - тогда конечно, и LDAP с плейн-текстом раем покажется...

[metaclass.livejournal.com]

Кстати, а не сделали ли в какой-то из новых версий MSSQL поддержку внешних файлов, как полноценных объектов базы данных? Что-то я такое то-ли читал, то-ли слышал.

[ennor.livejournal.com]

Не припомню такого. Да и как это сделаешь - если к такому объекту можно получить доступ в обход БД, то ACID сразу же накрывается медным тазом. А если нельзя, то какие же это "внешние файлы"? :)

[metaclass.livejournal.com]

FILESTREAM option</>
Да, внешние эти файлы только формально, в обход MSSQL доступ к ним не получишь.

[ennor.livejournal.com]

А, вот оно что. Ну, это только в 2008 будет, а я его еще не щупал - видимо, ближайший CTP ставить буду.

Но, зная Microsoft, могу заранее сказать, что там тоже будет куча оговорок и неожиданных приколов в плане неочевидности. Взять хотя бы то, что они сделали этот тип на основе varbinary(max), сняв с него ограничение 2Г - бля буду, что полностью снять это ограничение у них с первой попытки не получится :))).

[ennor.livejournal.com]

Вот, кстати - на ловца и зверь бежит:

SQL Server 2008 Filestream: Why?

Времена простых и однозначных решений давно прошли, как видишь.