Реализация пользовательских полей с помощью ALTER TABLE

Question

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

Я понимаю, что существуют различные способы реализации пользовательских полей (например, с помощью таблицы имен / значений или таблицы изменения и т. Д.), И в настоящее время мы предпочитаем использовать ALTER TABLE для динамического добавления новых пользовательских полей в базу данных.

После просмотра других связанных с этим тем SO, я не смог найти больших недостатков этого решения. Напротив, возможность быстрого запроса данных (например, путем непосредственного использования SQL-оператора where) является для нас большим преимуществом.

Есть ли какие-либо недостатки, о которых вы могли бы подумать, реализовав пользовательские поля таким образом? Мы говорим о веб-приложении, которое одновременно используют до 100 пользователей (не одновременных запросов ...) и могут использовать базы данных MySQL и MS SQL Server.

Answer 1

Первый недостаток, который я вижу, заключается в том, что вам необходимо предоставить сервису приложений права ALTER.
Это подразумевает, что ваша модель безопасности нуждается в тщательном внимании, поскольку приложение сможет не только добавлять поля, но и удалять и переименовывать их, а также создавать некоторые таблицы (по крайней мере, для MySQL).

Во-вторых, как бы вы различали поля, обязательные для пользователя? Или к полям, созданным пользователем A, может обратиться пользователь B?

Обратите внимание, что количество элементов в столбцах также может значительно возрасти. Если каждый пользователь добавляет 2 поля, мы уже говорим о 200 полях.

Лично я бы использовал один из двух подходов или их комбинацию:

1. Использование сериализованного поля

Я бы добавил одно текстовое поле в таблицу, в которой я бы хранил сериализованный словарь или словари:

{ 
  user_1: {key1: val1, key2, val2,...}, 
  user_2: {key1: val1, key2, val2,...}, 
  ...
}

Недостатком является то, что значения не легко найти.

2. Использование таблицы с несколькими типами имя / значение

таблица полей:

user_id: int
имя_поля: varchar (100)
тип: enum ('INT', 'REAL', 'STRING')

таблица значений:

field_id: int
row_id: int # идентификатор строки главной таблицы
int_value: int
float_value: float
text_value: text

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

Answer 2

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

Answer 3

Я не вижу ничего плохого в добавлении новых настраиваемых полей в таблицу базы данных.

При таком подходе можно использовать конкретный / наиболее подходящий тип, т. Е. Нужно ли поле int? определить его как int. Принимая во внимание, что с таблицей типа имя / значение вы будете хранить несколько типов данных как один тип (вероятно, nvarchar) - если вы не заполните эту таблицу имя / значение несколькими столбцами разных типов и не заполните соответствующий, но это немного ужасно .

Кроме того, добавление новых столбцов облегчает запрос / не требует включения объединения с новой таблицей имя / значение.

Это может показаться не таким общим, но я чувствую, что это лучше, чем иметь таблицу имен / значений "один размер подходит всем".

С точки зрения SQL Server (начиная с 2005 года) ....
В качестве альтернативы можно было бы создать 1 поле «пользовательских данных» типа XML - это было бы действительно универсально и не требовало бы создания полей или необходимости отдельной таблицы имя / значение. Также имеет то преимущество, что не все записи должны иметь одинаковые пользовательские данные (т. Е. Одно поле является общим, но то, что оно содержит, не обязательно). Не 100% влияния на производительность, но данные XML могут быть проиндексированы.