SQL Antipatterns

[beldmit]

Дочитал книгу "SQL Antipatterns". Книга понравилась.

Непрограммисты могут сходить по ссылке полюбоваться обложкой. Программисты - под кат.



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

Набор антипаттернов показался до боли знакомым. За 10 лет я по ним прошелся полностью. И некоторое количество шишек набил, и подпорки ставил. Кое-где не ходил, потому что глупость подхода очевидна. Рассмотрено хранение деревьев, хранение однородных атрибутов, хранение файлов, хранение "расширенных" атрибутов, простейший ORM, рассказано про оптимизацию запросов.

Автор ограничивается стандартом SQL. Поэтому, например, типы данных для массива и hstore - плоский хеш для PostgreSQL, которые позволяют решать часть проблем, но в стандарте отсутствуют, им в качестве решений не упоминаются. А зря - хранить несколько однородных атрибутов, например телефонов, в массиве удобнее, чем в классической "правильной" реляционной схеме, а хеш гарантирует уникальность строкового атрибута и позволяет вешать внешний ключ - что тоже избавляет от недостатков хранения всех атрибутов в одной таблице.

Comments

[u-uka.livejournal.com]

(*бурчит*) Там микроскоп должен был быть на заднем плане...

А почему не надо файлы в базе хранить? У нас на работе такой холивар на эту тему... Я в стане противников, но из неоспоримых аргументов у меня только размер базы. А молодое поколение программеров уже кажись убедили в том, что size doesn't matter :(

[beldmit.livejournal.com]

В качестве аргументов за хранение - транзакционность. В качестве аргументов против - то, что на файловой системе с ними оперировать проще. И размер, да. И независимость хранения.

[shamanov.livejournal.com]

Аргументов против:
1. Файлы в БД не поддаются (ну по крайней мере еще 3-4 года назад не поддавались) любой массовой обработки типа натравливания поисковика, антивируса и прочего.
2. Неудобство массовых операций с файлами (тут вопрос размера транзакции, если файлы большие). Это операции типа check in
Аргумент за:
1. Удобно делать конкретную функцию и не надо заморачиваться настройкой дополнительных интерфейсов и доступов при работе системы.
2. Возможность интеграции системы управления правами непосредственно в БД.
3. Возможность настройки связей между файлами дополнительной. Правда есть куча систем типа svn, которые реализуют большинство необходимых дополнительных связей и группировок.
===============
На выходе получается: если храним файлы ради одной функции и интересно самостоятельное управление правами доступа, то можно и в БД (правда безо всяких антивирусов и прочего), а иначе точно не в БД.
Ну и на тему размера :) Размер имеет значение - особенно как требование к серверу БД.

[ask-ripe.livejournal.com]

Дима,

но есть же bfile?

[beldmit.livejournal.com]

Это что за зверь?

[ask-ripe.livejournal.com]

эээ - это тот самый велосипед, который вы изобретали в кмв...
http://download.oracle.com/docs/cd/B10501_01/appdev.920/a96591/adl12bfl.htm#99013
появился в 2001 году в 9i

гугл в помощь (осмысленные линки на русском (если вдруг tahiti не перевариваешь))
http://my-oracle.it-blogs.com.ua/post-31.aspx
http://my-oracle.it-blogs.com.ua/post-30.aspx
http://my-oracle.it-blogs.com.ua/post-61.aspx

[beldmit.livejournal.com]

Понял

[shaplov.livejournal.com]

Одно дело сказал апачу отдать статический файл, и уйти, а другое через скрипт этот файл перелопачивать, получая его из базы и отдавая апачу...

[alexkuklin.livejournal.com]

Лучше не апачу, а nginx-у :)
http://wiki.nginx.org/XSendfile

[dph.livejournal.com]

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

Вот сделают возможность ссылки на блоб, как на линуксовый файл - и вообще будет счастье )

[ask-ripe.livejournal.com]

Дим - вот конкретно это и есть bfile :)