Насущные грабли современных SQL СУБД

zabivator — 30.09.2010 Сильные стороны:
* Методология проектирования: ER-модели предоставляют простую форму формального описания сущностей. Правила перехода от ER-моделей к реляционной представлению (DDL-запросам) достаточно формализованы с одной стороны, а с другой являются достаточно гибкими: DBA может легко произвести денормализацию данных
* Развитые языки управления схемой данных (DDL) позволяют моделировать (создавать) большинство сущностей разрабатываемой системы каким угодно образом.
* Язык SQL является простым, высокоуровневым языком для генерации произвольных происходных данных из исходных.
* Наличие VIEW позволяет описывать производные данные "как будто" исходные.

Слабые стороны:
* Вносить изменения в имеющуюся схему базы весьма проблематично. Фактически, версионировать базы (управлять различными версиями одной и той же базы) приходится вручную, нет удобных способов производить автоматическую миграцию данных при изменении схемы. Добавили атрибут? Привет ALTER TABLE. Поменялись (упаси господь) связи? Welcome to hell.
* Слабая интеграция хранимых (генерируемых) данных с приложениями. Добавили новую таблицу в базу? Нужно отображать? Пишем запросы к таблицам, и интеграционный слой для сортировки по колонкам, фильтрации, показа/скрытия столбцов.
* Сложный и неочевидный тюнинг производительности. EXPLAIN, конечно, помогает, но местами настройка базы и переписывание запросов напоминает вуду и шаманство.

Большое количество ORM'ов и популярность NoSQL по большёму счёту спровоцирована ровно одним недостатком: пенальти между хранением данных в базе и их представлением в программе по их визуализации/раздаче.

Какие есть методы решения?
* Генерация схемы базы из модели иной формы. Прощай оптимизация и денормализация базы. Привет куча ad-hoc'ов.
* Генерация модели (классов, функций. структур) из базы. Не работает - данные в базе не содержат информацию про способ их визуализации. Иногда появляется всякие мета-описания, но производительность такого решения ужасающая.
* Переход к двухзвенкам. Требует монотонной ручной работы, развитых хранимых процедур, не имеет проблем первых двух подходов (см. ниже)

Два первых способа имеют более серьёзные проблемы:
* Двухфазный коммит. Данные нужно обновлять как в target language представлении так и базе. Что происходит с транзакциями и целостностью, пояснять, думаю, смысла не имеет.
* Слой кеширования и его инвалидация. Без trird-party кеша СУБД ляжет (если нет поддержки query result cache на уровне базы, естественно), с third-party кешом появляется куча геммороя типа его инвалидациии, особенно для производных данных.

Хрен его знает что с этим всем делать.

Забыл подписаться - искренне Ваш, Капитан Очевидность

Оставить комментарий

Популярные посты:

• Архив