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-19 03:53 pm (UTC)