Является ли использование нескольких таблиц желательным решением для работы с пользовательскими полями?

Question

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

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

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

Дополнительная информация (метаданные?) О полях в динамически создаваемых таблицах может храниться в XML или в таблице «свойств».

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

У меня вопрос: есть ли другие способы решения этой проблемы с изменяемым полем, я иду по незнакомому пути?

Я полагаю, что EAV потребовал бы, чтобы у меня была таблица, определяющая поля для каждой спецификации импорта / сбора данных, а затем еще одна таблица с данными импорта - значения полей, и это кажется непрактичным.

Answer 1

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

Answer 2

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

Допустим, вы загружаете свои записи в user_records (id), эта таблица будет иметь столбец id, который является внешним ключом в таблицах пользовательских полей. Пользовательские строковые поля будут помещены в user_records_string (id, name), где id - это внешний ключ к user_records (id), а name - строка или внешний ключ к списку пользовательских строковых полей.

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

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

Это позволит вашей схеме быть статичной, а пользователь может произвольно добавлять поля и таблицы.

Answer 3

Какой вид каждого поля? Может ли тип поля отличаться для каждой записи?

Сейчас я работаю над программой, которая выполняет эту сортировку, и то, как мы ее обрабатываем, это в основном таблица записей, которая указывает на таблицу полей записей. таблица полей записи содержит все поля вместе с именем поля фактического поля в базе данных (имя столбца). Затем у нас есть таблица записей данных, в которую попадают все данные для каждой записи. Мы также храним record_id, сообщая ему, какую запись он хранит.

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

Я думаю, это то, о чем вы говорите ... поправьте меня, если я ошибаюсь.