строки с разными параметрами в MYSQL
 

Необходимо сделать небольшую админку, которая управляла бы формами ввода. Например есть 3 каких-то категории, у них есть формы ввода, но с разными полями. (т.е. в одном это поле color, name, id к примеру, а в другой direction, type, id).
вопрос заключается в следущем: как мне организовать запись таких данных в mysql в одну таблицу? т.е. у строк, в зависимости от категории будут разные имена столбцов. Имеет ли смысл делать столбцы для всех и забивать их NULL, если нет значения или лучше создать другую таблицу?

таких категорий(таблиц) планируется много. Т.е. и полей тоже немало (около 100 в общей сложности - т.е. по 3-5 полей от каждой категории.)

Надеюсь я понятно изложил проблему :). Готов объяснить еще подробней.
Спасибо.

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

hempsmoke
Создаешь столбец, где прописываешь тип категории + столбцы с данными, типа data1, data2, data3 и в зависимости от типа категории трактуешь данные по разному. Можно данные вынести в отдельные таблицы. По-моему так логично и понятно.

Merlin Cori
фактически да. часть формы у всех категорий однакова (name,email), а остальные разные.
т.е. ты предлагаешь в таблицу со столбцами id name mail color, если есть данные не для color, а для description, просто создать еще один столбец с именем description, а color заполнить NULL ?

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

Именно так

Merlin Cori
Так много пустых ячеек получится. Обычно так и делают.

hempsmoke
К таблице добавляешь столбец с типом данных + столбцы с самими данными(в количестве самого большого необходимого числа). В типе ты помечаешь что у тебя в данных хранится и в соответствии с этим обрабатываешь их.

>тогда как же мне сортировать такие данные?
После выборки естессно.

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

Merlin Cori
ну вот у меня и делемма - либо так, либо как Madness говорит. Тока я видно еще не допонял :)

hempsmoke
>еред каждым столбцом еще один вести столбец, который определяет тип следущего?
Бррр, это то накой. Вводишь столбец(data_id) в стоке которого пишешь "профиль", например, а в data1,2,3 - 'nick123','nick123@mail.ru','число постов например'. В своей проге пишешь че-нить типа select * from table where data_id='профиль' и распоряжаешься данными, как данными профиля. Иль, например, data_id='mail', тогда в data1,2,3 например такое - 'nick123@mail.ru','smtp.mail.ru','pop.mail.ru'. И т.д. Соответственно вся логика в программе должна быть.

ЗЫ. Делай как Merlin Cori грит, гемора меньше ;)

Madness
ну да, я так и думал :))

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

Имхо, хранить кучу данных в одной ячейке, которые могут обновляться независимо - не есть гуд.
Есть еще вариант, который у меня в свое время неплохо работал. Делаем три колонки в таблице:
itemId, fieldType, fieldValue.
Каждый объект, который нужно поместить в таблицу, имеет свой itemId. Для него мы имеем столько записей, сколько полей у этого объекта, с разными значениями fieldType (описывающими тип поля) и fieldValue (его значение). К примеру, если взять в качестве примера объекта "профиль" с id=3 и полями name, password и email, то в таблице для него получим следующее:

3 name Vasya
3 password qwerty
3 email asd@qwe.ru

UNIQUE KEY = (itemId, fieldType)
Ессно, fieldType лучше делать не текстовыми, а enum или внешним ключом в отдельную таблицу описаний. При этом получаем очень гибкую систему с любым количеством полей и отсутствием пустых избыточных ячеек.

по аналогии сделано хранение настроек в SquirellMail - кстати и сам довольно часто использую

уххх, спасибо. буду пробовать.

Это все здорово, но с точки зрения структуры (да и производительности в большинстве случаев), если это можно вписать в конечное количество отдельных таблиц то наверное так и логичнее будет сделать. Почему этот вариант отбросили?

думал об этом, просто неизвестно сколько этих категорий будет. 20-30?

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