2012-02-03 2 views
2

Я хочу создать систему, в которой администратор может создавать формы с программой, а пользователи вводят данные в эти формы. Кроме того, администраторы должны иметь возможность вводить любые имена полей в свои формы, даже выбираемые вопросы с множественным выбором. Только ответ, который я могу придумать, создает огромный текстовый блок для каждого типа формы, сгенерированного и сохраняющего поля формы, имена, варианты и т. Д., Сериализуя их из массива или объекта. Я бы сохранил ответы пользователей в сериализованных массивах в другом текстовом блоке, назначив каждому из них свои позиции в массивах.Лучший способ сохранить динамические поля базы данных?

Есть ли лучший подход для решения этой проблемы?

+0

Я начал раздражаться этим идиотским стандартным материалом Q & A. Мне жаль, но мне нужна эта информация от кого-то, у кого есть хоть какой-то опыт по этому поводу, и люди помогли мне, если вы можете просто немного прокрутить вниз. Не было лишней дискуссии о том, что лучше, а другие отстой. Кроме того, это может быть тот момент, когда один из ответчиков мог бы сказать: «Не делайте этого с базой данных, вот лучший способ». И это важно для меня тоже. Я думаю, что это нацисты, подобные закрытию ответа, являются причиной S.O. начнет падать. Не нарушайте великое сообщество, как солнце – gkaykck

ответ

4

EAV data model может удовлетворить ваши цели здесь. Просто имейте в виду, что вы будете платить за гибкость с некоторыми недостатками, такими как отсутствие ссылочной целостности и длинные запросы для извлечения данных (каждый атрибут, который вы хотите вернуть, требует другого JOIN).

0

Не могли бы вы создать таблицу в базе данных под названием «Поля»? Каждое поле имеет тип и текст. Затем также есть таблица с именем options, которая содержит другое текстовое поле для параметров, а также fk, указывающее на таблицу «fields». Также может быть таблица форм, в которой таблица полей имеет значение fk. В коде для приложения вы можете посмотреть поле и определить, нужно ли вам выбрать параметр. Это подход к реляционной базе данных. Некоторые из баз данных объектов, таких как Mongo, могут справиться с этим намного лучше.

Чтобы подвести итог:

Таблица: Форма Колонка: form_id PK

Таблица: Поле Колонка: FIELD_ID ПК Колонка: Текст Колонка: Тип Колонка: form_id (ФК)

Таблица: Параметры Столбец: Option_ID Столбец: Текст Столбец: Field_ID (FK)

2

Есть много способов, которыми вы можете продолжить это. Поскольку вы работаете с реляционной базой данных, одним из вариантов является просмотр Entity-Attribute-Value model. Фактически, этот подход переключает вашу структуру данных из предопределенной схемы (столбцов) в строки. Есть много недостатков этой гибкости, и вы часто в конечном итоге создаете кучу представлений, чтобы представить некоторые из этих «повернутых» данных в виде более традиционной таблицы.

Некоторые реляционные базы данных предоставляют функции типа noSQL, поэтому вы можете найти решение по этой дороге. PostgreSQL, например, имеет тип hstore, который позволяет хранить наборы пар ключ-значение в одном значении. Я понимаю, что вы не упоминали PostgreSQL в своем вопросе, но так, чтобы вы знали о том, что там, они также работают над собственным типом данных JSON и набором функций для 9.2. В сочетании с функциональными индексами это может обеспечить некоторые интересные возможности реляционных/noSQL-гибридов без чего-то вроде Redis или MongoDB.

Смежные вопросы