Альтернатива сущности / атрибута - динамически создаваемые таблицы
Мне нравится чистый реляционный дизайн, но иногда возникает необходимость в методе хранения данных Entity / Value. Особенно там, где пользователю нужно часто создавать новый тип данных.
Я видел в некоторых коммерческих программах, что они динамически создают стандартные таблицы, а не используют таблицы EV.
Очевидно, что это не комплексное решение, и оно может работать только в том случае, если вы ограничите типы данных, которые вы можете определить. Однако он имеет следующие преимущества:
- Модель четко определена - вам не нужно исследовать схему, чтобы понять ее.
- Вы получаете лучшую производительность, поскольку таблицы содержат только данные для этого типа данных, поэтому не нужно запрашивать явно несвязанные строки.
- Точно так же индексы содержат только значения для типа данных, которые определяет таблица, что опять же повышает производительность. (т.е. в модели EV, если индекс равен valueid, entityid - вы будете искать значения для сущностей, которые не имеют ничего общего с вашим запросом - если вы не разделите индекс).
Так что для меня это звучит здорово, но пропустите эту идею мимо администратора базы данных, и вы получите много зубов. Это хорошая идея, каковы подводные камни, и пробовал ли кто-нибудь это сделать?
Ответы 2
Прежде всего: приложение не должно иметь возможность изменять структуру базы данных, потому что у них не должно быть на это прав.
Во-вторых: я думаю, что накладные расходы на создание хорошего решения для создания структуры базы данных хорошо «на лету» не окупятся.
В-третьих: это может вызвать серьезные побочные эффекты с другими вещами, использующими базу данных (резервное копирование и поддержка скриптов, других приложений и т. д.), Если все сделано неправильно.
Не так давно я создал приложение для онлайн-опросов. Я использовал гибридную форму в качестве схемы базы данных:
- Первоначально сохраните значения в таблице "ключ-значение".
- Используйте динамические временные таблицы, поскольку пары ключ / значение преобразуются в настраиваемую таблицу для каждого опроса.
- Заполнение этих временных таблиц может быть выполнено с помощью одного тяжелого оператора
INSERT INTO temp_table SELECT ..., используя множествоLEFT JOIN.
Этот подход был идеальным для этого конкретного приложения, потому что опрос обычно включает этап, на котором вводятся ответы, и этап, на котором результаты анализируются.
- Создание временной таблицы иногда могло занимать много времени, но это нужно было сделать только один раз после закрытия опроса.
- Запрос таблицы результатов после этого был очень быстрым.
- Временные таблицы автоматически воссоздаются, если они были удалены или устарели. Из-за этого их не нужно было резервировать.
Итак, мой совет: подумайте о предполагаемом использовании. Этот пример сработал только из-за особых требований этого приложения. Вы в основном вставляете и обновляете значения (OLTP)? Или вы хотите выполнять агрегированные запросы (OLAP)? Постройте свою схему согласно ответу на этот вопрос.