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

0
pistolshrimp 18 Ноя 2010 в 03:46

3 ответа

Лучший ответ

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

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

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

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

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

3
James Anderson 18 Ноя 2010 в 04:25
Спасибо, Джеймс. На самом деле у меня будет схема полей формы в таблице (с целым набором атрибутов полей) вместо xml. Эта часть действительно хорошо работает. Кроме того, сериализованные данные, передаваемые туда и обратно, работают довольно хорошо. Я думаю, было бы лучше спросить клиента, понадобится ли ему поиск на уровне поля, и отказаться от своего ответа (да: создать столбец для каждого поля, нет: сериализовать)
 – 
pistolshrimp
18 Ноя 2010 в 07:46

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

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

2
alex 18 Ноя 2010 в 03:51
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
cababunga 18 Ноя 2010 в 05:05
Это решение сломается, как только в форме появится повторяющийся раздел. Предположим, что в форме есть раздел для «хобби», вам нужно сохранить «хобби-1», «хобби-2» и т. Д. Также поиск с осмысленными результатами поиска становится действительно беспорядочным. Как бы вы сделали "выберите имя, фамилию, почтовый индекс, где хобби =" Коллекционирование марок "и доход> 250000.
 – 
James Anderson
18 Ноя 2010 в 04:32
По крайней мере, для первой из ваших проблем вы можете закодировать эту логику в своем приложении, в то время как с таблицей из 500 полей вы вообще ничего не можете сделать. Что касается второй части, я обновлю свой ответ через минуту.
 – 
cababunga
18 Ноя 2010 в 04:57
У этого антипаттерна должно быть официальное название - «Динамическое решение статической задачи». Что бы вы ни делали, новый атрибут потребует макета, проверки и изменения кода, другой столбец db - не такая уж большая дополнительная работа. Кроме того, если вы используете фреймворк типов rails / grails, большая часть этого кода предоставляется бесплатно, когда вы добавляете столбец в свою схему.
 – 
James Anderson
18 Ноя 2010 в 11:33
Джеймс, в конце концов вы поймете, что самая большая головная боль, которую вы можете испытывать, - это изменение схемы базы данных, когда ваша система находится в производственной среде и накопила много данных.
 – 
cababunga
18 Ноя 2010 в 11:44