Правильный способ хранения пользовательских данных в SQL

Question

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

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

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

Одна базовая таблица, которая будет содержать каждый идентификатор формы, URL и т. Д.

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

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

Answer 1

хранить пользовательские данные в SQL

Я думаю, что вы ищете модель базы данных Entity–attribute–value, в которой:

Основная идея заключается в хранении атрибутов и их соответствующих значений в виде строк в одной таблице.

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

Смотрите эти страницы как начало:

• Использование метаданных базы данных и ее семантики для создания автоматических и динамических веб-форм ввода (pdf)

• Планирование и внедрение цифрового репозитория на основе метаданных (pdf)

Я пометил ваш вопрос тегом /questions/tagged/entity-attribute-value, в котором вы можете просмотреть множество тем, относящихся к вашему делу.

Answer 2

Как пишет Махмуд Гамаль, модель, которую вы описываете, является "сущность / атрибут / ценность"; Как пишет Борис, с этой моделью известно много проблем.

В качестве альтернативы вы можете рассмотреть возможность сохранения записей формы в "документе" - например, XML или JSON - в реляционной модели.

Например, у вас может быть таблица в соответствии с:

FORM_SUBMISSION
--------------------
Submission_ID (pk)
Client_ID (fk to clients table)
Submission_date
SubmissionDocument

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

Эта модель усложняет выполнение SQL-запросов к отправке формы (хотя это становится сложным и для EAV, когда выходят за рамки очень простых запросов), но значительно упрощает постоянное решение.