SQL Antipatterns
Dec. 19th, 2010 12:18 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
beldmitДочитал книгу "SQL Antipatterns". Книга понравилась.
Непрограммисты могут сходить по ссылке полюбоваться обложкой. Программисты - под кат.
С автором я согласен почти во всем. Собственно, единственное место, где не согласен - это идея хранить файлы в базе. Да, есть ситуации, когда это упрощает жизнь, но для известных мне случаев это неверно.
Набор антипаттернов показался до боли знакомым. За 10 лет я по ним прошелся полностью. И некоторое количество шишек набил, и подпорки ставил. Кое-где не ходил, потому что глупость подхода очевидна. Рассмотрено хранение деревьев, хранение однородных атрибутов, хранение файлов, хранение "расширенных" атрибутов, простейший ORM, рассказано про оптимизацию запросов.
Автор ограничивается стандартом SQL. Поэтому, например, типы данных для массива и hstore - плоский хеш для PostgreSQL, которые позволяют решать часть проблем, но в стандарте отсутствуют, им в качестве решений не упоминаются. А зря - хранить несколько однородных атрибутов, например телефонов, в массиве удобнее, чем в классической "правильной" реляционной схеме, а хеш гарантирует уникальность строкового атрибута и позволяет вешать внешний ключ - что тоже избавляет от недостатков хранения всех атрибутов в одной таблице.
Непрограммисты могут сходить по ссылке полюбоваться обложкой. Программисты - под кат.
С автором я согласен почти во всем. Собственно, единственное место, где не согласен - это идея хранить файлы в базе. Да, есть ситуации, когда это упрощает жизнь, но для известных мне случаев это неверно.
Набор антипаттернов показался до боли знакомым. За 10 лет я по ним прошелся полностью. И некоторое количество шишек набил, и подпорки ставил. Кое-где не ходил, потому что глупость подхода очевидна. Рассмотрено хранение деревьев, хранение однородных атрибутов, хранение файлов, хранение "расширенных" атрибутов, простейший ORM, рассказано про оптимизацию запросов.
Автор ограничивается стандартом SQL. Поэтому, например, типы данных для массива и hstore - плоский хеш для PostgreSQL, которые позволяют решать часть проблем, но в стандарте отсутствуют, им в качестве решений не упоминаются. А зря - хранить несколько однородных атрибутов, например телефонов, в массиве удобнее, чем в классической "правильной" реляционной схеме, а хеш гарантирует уникальность строкового атрибута и позволяет вешать внешний ключ - что тоже избавляет от недостатков хранения всех атрибутов в одной таблице.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-12-18 09:33 pm (UTC)no subject
Date: 2010-12-19 12:19 am (UTC)1. Файлы в БД не поддаются (ну по крайней мере еще 3-4 года назад не поддавались) любой массовой обработки типа натравливания поисковика, антивируса и прочего.
2. Неудобство массовых операций с файлами (тут вопрос размера транзакции, если файлы большие). Это операции типа check in
Аргумент за:
1. Удобно делать конкретную функцию и не надо заморачиваться настройкой дополнительных интерфейсов и доступов при работе системы.
2. Возможность интеграции системы управления правами непосредственно в БД.
3. Возможность настройки связей между файлами дополнительной. Правда есть куча систем типа svn, которые реализуют большинство необходимых дополнительных связей и группировок.
===============
На выходе получается: если храним файлы ради одной функции и интересно самостоятельное управление правами доступа, то можно и в БД (правда безо всяких антивирусов и прочего), а иначе точно не в БД.
Ну и на тему размера :) Размер имеет значение - особенно как требование к серверу БД.
no subject
Date: 2010-12-19 04:58 am (UTC)но есть же bfile?
no subject
Date: 2010-12-19 08:37 am (UTC)no subject
Date: 2010-12-19 09:13 am (UTC)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
no subject
Date: 2010-12-19 09:21 am (UTC)