Альтернатива Entity / Attribute - динамически создаваемые таблицы

Question

Мне нравится чистый реляционный дизайн, но иногда требуется метод хранения данных Entity / Value. Особенно там, где пользователю необходимо часто создавать новый тип данных.

Я видел в некоторых коммерческих программах, что они динамически создают стандартные таблицы, а не используют таблицы EV.

Очевидно, что это не решение для всех и может работать, только если вы ограничиваете типы данных, которые вы можете определить. Тем не менее, он имеет следующие преимущества: -

• Модель четко определена - вам не нужно опрашивать схему, чтобы понять схему.
• Вы получаете более высокую производительность, поскольку таблицы содержат только данные для этого типа данных, поэтому нет необходимости запрашивать явно не связанные строки.
• Аналогично, индексы содержат значения только для того типа данных, который определена в таблице, что снова повышает производительность. (то есть в модели EV, если индекс имеет значение valueid, entityid - вы будете искать значения для сущностей, которые не имеют никакого отношения к вашему запросу - если вы не разбили индекс на части).

Так что для меня это звучит замечательно, но пропустите эту идею через DBA, и вы получите много сосущих зубов. Это хорошая идея, какие подводные камни, и кто-нибудь пытался это сделать?

Answer 1

Прежде всего: приложение не должно иметь возможности изменять структуру базы данных, потому что у него не должно быть прав для этого.

Во-вторых: я думаю, что затраты на создание хорошего решения для создания хорошей структуры базы данных на лету не окупятся.

В-третьих: это может привести к серьезным побочным эффектам с другими вещами при использовании базы данных (резервное копирование и поддержка сценариев, других приложений и т. Д.) При неправильном выполнении.

Answer 2

Не так давно я создал приложение для онлайн-опросов. Я использовал гибридную форму в качестве схемы базы данных:

• Первоначально сохранить значения в таблице ключ / значение.
• Используйте динамические временные таблицы, так как пары ключ / значение преобразуются в пользовательскую таблицу для опроса.
• Заполнение этих временных таблиц может быть выполнено с помощью одного тяжелого оператора INSERT INTO temp_table SELECT ... с использованием большого числа LEFT JOIN с.

Этот подход был идеальным для данного конкретного приложения, потому что опрос обычно имеет фазу, на которой вставляются ответы, и фазу, на которой анализируются результаты.

• Построение временной таблицы иногда может занимать много времени, но это нужно было сделать только один раз после закрытия опроса.
• Запрос к таблице результатов впоследствии был очень быстрым.
• Временные таблицы, где автоматически воссоздаются, если они были удалены или устарели. Из-за этого их не нужно было резервировать.

Так что мой совет: подумайте о том, для чего предназначается. Этот пример разработан только из-за особых требований этого приложения. Вы в основном вставляете и обновляете значения (OLTP)? Или вы хотите запускать агрегированные запросы (OLAP)? Постройте свою схему согласно ответу на этот вопрос.