![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
SQL Antipatterns
Дочитал книгу "SQL Antipatterns". Книга понравилась.
Непрограммисты могут сходить по ссылке полюбоваться обложкой. Программисты - под кат.
С автором я согласен почти во всем. Собственно, единственное место, где не согласен - это идея хранить файлы в базе. Да, есть ситуации, когда это упрощает жизнь, но для известных мне случаев это неверно.
Набор антипаттернов показался до боли знакомым. За 10 лет я по ним прошелся полностью. И некоторое количество шишек набил, и подпорки ставил. Кое-где не ходил, потому что глупость подхода очевидна. Рассмотрено хранение деревьев, хранение однородных атрибутов, хранение файлов, хранение "расширенных" атрибутов, простейший ORM, рассказано про оптимизацию запросов.
Автор ограничивается стандартом SQL. Поэтому, например, типы данных для массива и hstore - плоский хеш для PostgreSQL, которые позволяют решать часть проблем, но в стандарте отсутствуют, им в качестве решений не упоминаются. А зря - хранить несколько однородных атрибутов, например телефонов, в массиве удобнее, чем в классической "правильной" реляционной схеме, а хеш гарантирует уникальность строкового атрибута и позволяет вешать внешний ключ - что тоже избавляет от недостатков хранения всех атрибутов в одной таблице.
Непрограммисты могут сходить по ссылке полюбоваться обложкой. Программисты - под кат.
С автором я согласен почти во всем. Собственно, единственное место, где не согласен - это идея хранить файлы в базе. Да, есть ситуации, когда это упрощает жизнь, но для известных мне случаев это неверно.
Набор антипаттернов показался до боли знакомым. За 10 лет я по ним прошелся полностью. И некоторое количество шишек набил, и подпорки ставил. Кое-где не ходил, потому что глупость подхода очевидна. Рассмотрено хранение деревьев, хранение однородных атрибутов, хранение файлов, хранение "расширенных" атрибутов, простейший ORM, рассказано про оптимизацию запросов.
Автор ограничивается стандартом SQL. Поэтому, например, типы данных для массива и hstore - плоский хеш для PostgreSQL, которые позволяют решать часть проблем, но в стандарте отсутствуют, им в качестве решений не упоминаются. А зря - хранить несколько однородных атрибутов, например телефонов, в массиве удобнее, чем в классической "правильной" реляционной схеме, а хеш гарантирует уникальность строкового атрибута и позволяет вешать внешний ключ - что тоже избавляет от недостатков хранения всех атрибутов в одной таблице.
no subject
А почему не надо файлы в базе хранить? У нас на работе такой холивар на эту тему... Я в стане противников, но из неоспоримых аргументов у меня только размер базы. А молодое поколение программеров уже кажись убедили в том, что size doesn't matter :(
no subject
no subject
1. Файлы в БД не поддаются (ну по крайней мере еще 3-4 года назад не поддавались) любой массовой обработки типа натравливания поисковика, антивируса и прочего.
2. Неудобство массовых операций с файлами (тут вопрос размера транзакции, если файлы большие). Это операции типа check in
Аргумент за:
1. Удобно делать конкретную функцию и не надо заморачиваться настройкой дополнительных интерфейсов и доступов при работе системы.
2. Возможность интеграции системы управления правами непосредственно в БД.
3. Возможность настройки связей между файлами дополнительной. Правда есть куча систем типа svn, которые реализуют большинство необходимых дополнительных связей и группировок.
===============
На выходе получается: если храним файлы ради одной функции и интересно самостоятельное управление правами доступа, то можно и в БД (правда безо всяких антивирусов и прочего), а иначе точно не в БД.
Ну и на тему размера :) Размер имеет значение - особенно как требование к серверу БД.
no subject
но есть же bfile?
no subject
no subject
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
no subject
no subject
http://wiki.nginx.org/XSendfile
no subject
Вот сделают возможность ссылки на блоб, как на линуксовый файл - и вообще будет счастье )
no subject
no subject
no subject
no subject
а нестандартные расширения SQL автор правильно не рассматривает)
no subject
А почему, собственно, не рассмотреть? Особенно если к базе ты привязан. То есть в общей книге да, не надо.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
2b || !2b
no subject
http://www.msteched.com/2010/NorthAmerica/DAT316
сильно эту практику ругает. Начиная с 36ой минуты.
Я лично тоже как-то не люблю и не делаю. Файловые репозитории это наше всё ;)
no subject
no subject
Выступает за хранение файлов на NFS, и пускай админы это прекрасно админят.
А видео зря, видео - эт наше всё )