Разработка базы данных для создателя пользовательских форм (и хранение результатов)

Question

Я пытаюсь реализовать пользовательский конструктор форм, аналогичный представленному Wufoo и Google .

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

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

Вопросы:

1. Есть ли лучший способ сохранить дизайн формы?
2. Какие структуры данных / модели подходят для хранения результатов формы? Я видел, что EAV может быть возможностью, но из-за различных типов ввода (раскрывающийся список, флажок, текст, текстовое поле) это может стать утомительным. Какая структура позволила бы упростить поиск и разрешить использование предложений WHERE? Приведенный пример JSON не позволяет мне делать это так же хорошо

Answer 1

EAV работает довольно хорошо, так как вы часто можете отображать значения карты на несколько основных типов. В личном проекте у нас есть таблица с:

entity_id     : INTEGER REFERENCES entities(id)
attr_id       : INTEGER REFERENCES attributes(id)
value_bool    : BOOLEAN
value_int     : INTEGER
value_string  : VARCHAR
value_text    : TEXT

А информация об attr_id хранится в другой таблице, где мы можем найти атрибут Тип и имя и тому подобное. Кроме того, разница между строкой и текстом заключается в том, что текст может иметь индекс поиска «полный текст», в то время как строка - это только базовое индексирование соответствия.

Когда вы хотите запросить attrbute, вы ищите его в таблице атрибутов, затем создаете запрос, устанавливая правильное условие, например "WHERE attr_id = 12 AND value_string = 'sfds'".

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

CREATE INDEX test ON eav(attr_id, value_int) WHERE value_int IS NOT NULL;

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

Answer 2

EAV является допустимым вариантом - он может быть сложным и неудобным с тем, что фактически превращается в нетипизированные данные.

XML с XPath также может быть вариантом: http://dev.mysql.com/tech-resources/articles/xml-in-mysql5.1-6.0.html

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