2012-07-03 5 views
4

Мне нужно разрешить создание пользовательской формы с помощью веб-интерфейса в моем программном обеспечении. то есть они создают вопрос, тип (текст, радио, флажки и т. д.), параметры, если необходимо (радио/проверка), а затем добавлять и продолжать в этом процессе, пока они не создадут все поля в форме.Какой datastore использовать для пользовательских форм - Любые преимущества с NoSQL для EAV

Запросов не будет сделано против них, кроме как просмотреть/заполнить/распечатать их, то есть они добавляют «вопросники», которые могут быть заполнены неограниченное количество раз (некоторые могут быть 20 раз, несколько миллионов раз).

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

Было бы одно возможное значение для некоторых полей (text/text_area/date), но у многих также было бы несколько опций (переключатели, выбор падений, флажки).

Вот образец дизайна в традиционном SQL:

форма: creator_id, имя

form_field: form_id, заказ, вопрос, тип (текст, text_area, дата, радио, выберите, чек)

form_field_option: form_field_id, имя, значение, порядок (используются для радио/выбора/проверки)

form_result: form_id, application_id (не имя я использую, но все результаты будут принадлежать к 'приложению')

form_field_value: form_result_id, form_field_id, form_field_option_id, значение (если поле опций значение будет пустым, поле текста form_field_option_id будет пустым)

Казалось бы, довольно легко построить формы, основанные на этом и получить Результаты. Это может быть или не быть точно эффективным, но сказать, что типичная форма составляет 5-30 вопросов, было бы так плохо?

Есть ли какие-либо преимущества в том, чтобы поместить это в базу данных NoSQL, то есть Mongo или что-то подобное? Если да, то можете ли вы дать мне конкретные примеры того, что они собой представляют, и дать мне образец дизайна? Я видел много ответов, таких как «NoSQL лучше подходит для этого», но у меня нет опыта в этой области, из-за более быстрого поиска результатов или чего? И какие недостатки будут использовать NoSQL?

Благодаря

ответ

9

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

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

Это ЯМЛ только потому, что он чище писать, чем JSON. Основная структура будет такой же.

_id: 12345 
creator: Adrian 
name: NoSQL form demonstrator 

fields: 
    - id: first_name 
    label: First name 
    type: text 
    required: true 

    - id: last_name 
    label: Last name 
    type: text 
    required: true 

    - id: dob 
    label: Date of birth 
    type: date 

    - id: bio 
    label: Biography 
    type: textarea 

    - id: drink 
    label: What would you like to drink? 
    type: select 
    options: 
     - id: tea 
     label: Tea 
     - id: coffee 
     label: Coffee 
     - id: beer 
     label: Beer 
     - id: water 
     label: Mineral water 

    - id: mailing_list 
     label: Join our mailing list? 
     type: check 
     default: false 

Примечание:

Вам только нужно хранить ключи, где они нужны вы вместо того, чтобы столбец для каждой вещи в любом контексте, как вы бы в реляционной базе данных. например нет необходимости в required: false - если это значение по умолчанию, просто оставьте его.

Документы MongoDB имеют встроенный порядок, поэтому нет необходимости создавать поле для хранения заказов полей в дизайне формы.

Результаты формы будут храниться таким же образом. Просто сохраните их, как и следовало ожидать:

_id: 545245 
form_id: 12345 
name: NoSQL form demonstrator 

results: 
    - id: first_name 
    label: First name 
    type: text 
    value: Adrian 

    - id: last_name 
    label: Last name 
    type: text 
    value: Short 

    - id: dob 
    label: Date of birth 
    type: date 
    value: 1970-01-01 

    - id: bio 
    label: Biography 
    type: textarea 
    value: Doing things on the internet 

    - id: drink 
    label: What would you like to drink? 
    type: select 
    value: Tea 

    - id: mailing_list 
    label: Join our mailing list? 
    type: check 
    value: false 
+0

Спасибо за ответ. Я все еще пытаюсь склонить голову вокруг того, как работает что-то вроде манго, но определяете ли вы структуру формы в YAML выше? Я хочу, чтобы конечный пользователь через веб-интерфейс мог определять структуру формы. т.е. выберите этот вопрос/элемент - Добавить, повторить до завершения. Похоже, что выше этого они не могут этого сделать - снова я новичок в этом, поэтому, если я что-то пропущу, объясните, пожалуйста. Спасибо – riley

+0

Это всего лишь один из возможных примеров. Схемы MongoDB являются динамическими, то есть схема определяется в каждом документе, а не в таблице (коллекции) в целом. Точно так же, как вы напишете в БД для MySQL, вы должны написать эту структуру в качестве документа MongoDB. Для каждой формы это было бы по-другому. –

+0

Разве вы не хотите/не должны определять какую-то базовую структуру для коллекции, чтобы при использовании данных (т.е. дисплее) вы знали, что искать там? т.е. я смотрю на Mongoid (Ruby abstract для БД). Примеры показывают классы (коллекции?) С полями и типами полей. Разве это не нужно? – riley

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

  • Нет связанных вопросов^_^