На днях встал вопрос о проектировании одной таблицы БД...

в форме это выглядит так...

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

так вот в чем проблема...
как это хранить в БД, получатся некая таблица в поле которой это будет выглядеть не иначе как 1,0,0,1,0....ну или что-то в этом роде....не хотелось бы с этим возиться, может кто-то что-то подобное у себя проворачивал в более оптимальном варианте...

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

Интересует вариант с таблицами БД...

тут есть два варинта:
1. все профайлы хранятся в одной таблице, максимально охватывающей все возможные "подчеки" (аттрибуты)
2. есть несколько таблиц для одной группы, для другой и т.д. но тогда выборка может стать геммороем 

почему только два? вариантов всегда не менее 3. 
вот только информации мало - не понятно, что за "подчеки", аттрибуты и т.д.

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

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

skyboy, ну -1 (как самый плохой) итого 2 

Render, тут проблема специфичная и информации все равно мало.

Сейчас попробую описать, подробнее...

Вообщем у меня есть форма:



Что-то в этом роде....
теперь инфу о заказе надо писать в БД, вот только как там держать чеки и селекты...насчёт файлов и доп. инфы всё ясно отдельное поле, а вот как быть с этими вопрос...либо чеки писать прямо по называниям, то есть в поле это будет сидеть в виде текста: target1,target3...отдельное поле и для селектов можно....только никак вообразить вставку таких данных немогу...

Render, ты можешь не форму давать, а выдать сжатое ТЗ: какие объекты, какие связи(я не про БД, а про информацияонные объекты, как самодостаточные информационные структуры)?

Render, ну это просто
делается по хорошему 3я таблицами:
1. люди. ключ user_id.
2. работы. поля соответственно:
work_id, user_id (чья работа), cat_id, target1 (tinyint), target2, target3 (при условии что их будет макс. 3! если нет, надо дальше нормировать), comment..
3. файлы. 
file_id, work_id, filename, file, mime
например.

Если кол-во статично, то используй множество или сам реализовывай список параметров через строку с разделителем. При этом порядок чекбоксов тоже статичный и определен программно.
В противном случае надо детально смотреть как устроены чекбоксы.

Не совсем понял что нужно описать чтобы подсобить ответу...   
Описать данные входящие в БД...
Связь между данными...в форме вроде бы всё и так описано какая у них связь...

Пардон если я что-то не правильно понял...

Vaulter ну это как раз то от чего я хотел уйдти, я про таргеты в int. Если предположим их со временем будет уже не 3...
То есть самый лучший вариант это хранить там, имя поля(услуги) хотя бы...чтобы потом всё это дело вывести...проблема сейчас у меня уже в том как это дело в БД писать...
С трудом представляю себе этот запрос, ну то есть вдруг чек не вкл...это правда уже тема в MySQL...
но всё же...

Это сообщение отредактировал(а) Render - 15.10.2006, 19:20

Render, если не 3 - то 4е таблицы.
ты хотел уйти от нормальной формы хранения данных?
зачем?
запросы получаются тривиальные.
тривиальные с точки зрения написания и с точки зрения субд.