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

Question

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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

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