2010-11-18 2 views
0

У меня есть форма с примерно 500 + полями (это 10-страничная форма, разные типы данных). Можете ли вы, ребята, посоветовать мне лучше всего хранить данные из формы? Я могу создать 500 полей в нескольких логически разделенных таблицах, но это кажется много (или, может быть, это лучший способ ?!), так как у меня есть несколько таких форм. Я изучаю сериализацию данных и их хранение в длинном текстовом поле mysql. Это будет иметь свои недостатки (я думаю, это то, что клиент хочет искать отдельные поля в будущем), но это похоже на довольно быстрое решение. Я буду признателен, если вы поделитесь опытом с аналогичной ситуацией.Рекомендации по хранению данных из сотен полей

ответ

3

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

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

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

Или вы можете определить XML-схему, содержащую все возможные поля в форме и т. Д., А также некоторую информацию о состоянии.

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

+0

Спасибо Джеймсу. У меня действительно будет схема полей формы в (с целым рядом атрибутов поля) вместо xml. Эта часть работает действительно красиво. Кроме того, сериализованные данные, идущие назад и вперед, работают очень красиво. Я думаю, было бы лучше спросить у клиента, если им понадобится поиск на уровне поля и уйти от ответа (да: сделать столбец для каждого поля, нет: сериализовать) – pistolshrimp

2

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

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

0
create table profile_details (
    user_id number, 
    field_name varchar, 
    field_value varchar 
); 

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

select firstname, lastname, zipcode 
from profiles p 
join profile_details d1 on (p.user_id=d1.user_id) 
join profile_details d2 on (p.user_id=d2.user_id) 
where d1.field_name='hobby' and d1.field_value='fishing' 
and d2.field_name='income' and d2.field_value>cast(250000 as number); 
+0

Это решение сломается, как только в форме будет повторяющийся раздел. Предположим, что у формы есть раздел для «хобби», тогда вам нужно хранить «хобби-1» «хобби-2» и т. Д. Также поиск со значимыми результатами поиска становится действительно беспорядочным. Как бы вы делали ", выберите firstname, lastname, zipcode, где hobby =" Stamp Collecting "и доход> 250000. –

+0

Для первой из ваших проблем, по крайней мере, вы можете закодировать эту логику в своем приложении, в то время как с 500-полевым столом вы можете Для второй части я собираюсь обновить свой ответ через минуту. – cababunga

+0

Должно быть официальное название этого анти-шаблона - «Динамическое решение статической проблемы». Что бы вы ни делали новый атрибут потребует компоновки, проверки и изменения кода, другой столбец db - это не большая работа. Плюс, если вы используете структуру типов rails/grails, большинство этого кода предоставляется бесплатно при добавлении столбца в вашу схему. –

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