Проектирование базы данных: практично ли изменять схему таблицы во время выполнения? - PullRequest
Новая
       0

Проектирование базы данных: практично ли изменять схему таблицы во время выполнения?

1 голос
/ 28 ноября 2010

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

 (reserved)
     __
    /  \
   /    \
--------------------------------------
| id | name | color | height | width | 
--------------------------------------

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

  • Можем ли мы исключить проблему безопасности, если единственное, что пользователь контролирует в операторах ADD/DROP COLUMN, - это имя поля (которое всегда будет проверяться, чтобы предотвратить удаление зарезервированных полей)?

  • Насколько дорогими могут стать ADD/DROP COLUMN операторы, когда таблицы становятся действительно большими? Предполагая, что у нас есть ограничение скорости, чтобы избежать злоупотребления системой со стороны пользователя.

  • Сколько (обнуляемых, неиндексированных) столбцов слишком много для одной таблицы с точки зрения производительности?

Ответы [ 4 ]

3 голосов
/ 28 ноября 2010

Вам было бы намного лучше, если бы была вторая таблица с парами ключ / значение.

А с чего вы взяли, что подход с использованием второй таблицы не будет запрашиваемым?

Операторы DDL не могут быть в транзакции. Вероятно, это будет зависеть от используемого вами механизма базы данных, но я не удивлюсь, если DDL придется ждать завершения каждой другой транзакции и / или блокировать все остальные транзакции в ожидании завершения других транзакций. Другими словами, производительность была бы отстойной.

0 голосов
/ 28 ноября 2010

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

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

0 голосов
/ 28 ноября 2010

Вместо добавления столбцов в существующую таблицу, как насчет создания второй таблицы, содержащей пары ключ-значение атрибутов с внешним ключом для таблицы продуктов? Это учитывает любое количество и разнообразие атрибутов для продуктов и легко запрашивается путем объединения таблиц с первичным ключом-внешним ключом.

0 голосов
/ 28 ноября 2010

Динамическое изменение схемы во время выполнения для реляционной базы данных чрезвычайно дорого и обычно может иметь некоторые негативные последствия (не до того, чтобы что-то развязать и съесть детей, но закрыть;))

Так что я бы посмотрел на два варианта.

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

  2. Рассмотрите возможность использования нереляционной базы данных, которая позволяет хранить разрозненные объекты (обычно в JSON и т. Д.)

...