Оптимальна структура таблицы

Xrobak

Guest
Оптимальна структура таблицы

Нужна помощь в создании оптимальной структуры таблицы. Что требуется:
1) есть форма, в которой есть 100 с хвостиком значений, эти самые значения будут чекбоксами, значение к-рых в последствии будут обрабатываться
2) возможно я ошибаюсь, но в данном случае использовать имена этих чекбоксов типа name1...100 нельзя. Объясню почему: сейчас чекбоксов у меня 100, со временем мне нужно будет добавить еще пару чекбоксов, и добавить не в конец таблицы, а к примеру один чекбокс после 35 чекбокса, другой перед 67 и т.п. Т.е. если я задам им имена name1...100, то данные, к-рые заполнялись до этих изменений в стурктуру таблицы сдвинутся.
3) нужно сделать так, чтобы название этих чекбоксов выбирались из БД (название тут подразумевается текстовое описание; пример: номеру чекбокса 35 соотвествует описание МАША). Это нужно для того, чтобы в саму заполнялку вывести эти значения и имена чекбоксов, а потом уже на другой страничке, на основании этих значений выводить информацию эту. Пример: холодильник - есть/хороший, светильник - нет, телефон - есть/плохой и т.п.
4) нужно чтобы каждый чекбокс дополнял <select> из двух значени: хорошо/плохо
5) ах да... забыл еще одно упомянуть - все эти чекбоксы разбиты на подгруппы. Пример: холодильники бывают однокамерные, двухкамерные и т.п. Телефоны бывают стационарные, мобильные... Это тоже нужно как-то учитывать в структуре таблицы.

Это будет форма-заполнялка, в обработке формы будет следующее:
- проверяем все чекбоксы на наличиен on/off и заносим в БД этот статус
- помимо статуса он/офф нужно проверить еще на каждый чекбокс значение <select>'а, т.е. "хорошо" или "плохо" было вбырано. В итоге получится что в БД должно занестись статус он/офф и гуд/бед

Самый "простой" (тупой способ) решения - вручную каждому чекбоксу даеш уникальное имя, при обработке формы пишеш 100 дурацких проверок на статус он/офф и гуд/бед и уже эти значения заносиш в БД. Все было бы хорошо если бы было этих чекбоксов меньше, можно было бы и вручную прописать, но их много и будет еще больше - каждый раз писать руками все - это не есть оптимально.

Что посоветуете в данной ситуации, как лучше организовать структуру таблицы/таблиц?
 

dnes

Новичок
Re: Оптимальна структура таблицы

Что посоветуете в данной ситуации, как лучше организовать структуру таблицы/таблиц?
Лучше организовать структуру таблицы/таблиц!
 

Xrobak

Guest
dnes
ты наверное слово КАК не увидел ;) Топик для этого как раз и поднимался, чтобы определиться со структурой таблиц/таблицы.

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

dnes

Новичок
Слово КАК я увидел.

Но это тебя не избавляет от необходимости продумать структуру базы данных. А в этом тебе безусловно поможет поиск по форуму.
 

yugene

Отошел от дел
Автор оригинала: Xrobak
2) возможно я ошибаюсь, но в данном случае использовать имена этих чекбоксов типа name1...100 нельзя. Объясню почему: сейчас чекбоксов у меня 100, со временем мне нужно будет добавить еще пару чекбоксов, и добавить не в конец таблицы, а к примеру один чекбокс после 35 чекбокса, другой перед 67 и т.п. Т.е. если я задам им имена name1...100, то данные, к-рые заполнялись до этих изменений в стурктуру таблицы сдвинутся.
Сделай дополнительное поле, по которому делай сортировку

Автор оригинала: Xrobak
3) нужно сделать так, чтобы название этих чекбоксов выбирались из БД
mysql_query()

Автор оригинала: Xrobak
5) ах да... забыл еще одно упомянуть - все эти чекбоксы разбиты на подгруппы. Пример: холодильники бывают однокамерные, двухкамерные и т.п. Телефоны бывают стационарные, мобильные... Это тоже нужно как-то учитывать в структуре таблицы.
Как это будет использоваться? Я так понял, у тебя просто есть чекбокс "холодильник", а не куча чекбоксов "холодильник Минск", "холодильник ЗИЛ", etc. Что групировать-то в эти подгруппы?

Автор оригинала: Xrobak
В итоге получится что в БД должно занестись статус он/офф и гуд/бед
Если выбрано "офф", то "гуд-бед" уже не актуально. Таким образом хватит 3 значений: 0 - "офф", 1 - "гуд", 2 - "бед". 1 и 2 автоматически подразумевают "он".
 

Sherman

Mephi
если я правильно понимаю.

товар.

item_ID(PK), item_Status,...

чекбоксы.

chkb_ID(PK), groupID(FK), chkb_Status,...

группы чекбоксов.

groupID(PK),...

таблица связи товар->чекбокс.

item_chkb_ID(PK), item_ID(FK), chkb_ID(FK), sel_ID(FK)

таблица типов select(хорошо, плохо, нормально, ...).

sel_ID (PK)


ты не указал версию mysql. если это 3-ка(3.23.58 например), то тогда придется реализоввывать FK самостоятельно(т.е. в клиентском коде, например), либо использовать таблицы innoDB(поддерживаются не всеми хостерами).

в 4.1 многие проблемы, касательно FK уже решены.

типизацию связей не проводил сознательно(т.е. по-умолчанию все связи неидентифицирующие) по той же самой причине, не указана версия СУБД.
 

Xrobak

Guest
Sherman
делаю на локалке - у меня мускул 4.0.5-бета, у хостера мускул 4.0.20
yugene
Сделай дополнительное поле, по которому делай сортировку
извини, не уловил ход твоих мыслей - чем это может мне помочь?
Если выбрано "офф", то "гуд-бед" уже не актуально. Таким образом хватит 3 значений: 0 - "офф", 1 - "гуд", 2 - "бед". 1 и 2 автоматически подразумевают "он".
оо... это правильнос казано, как я сразу не додумался до этого...

Так... примеры примерами, расскажу что на самом деле будет, ато с товарами немного не получилось. Это будет форма заполнения информации по отелям. Что я подразумевал под понятием разделение по группам: первая группа - что есть в номере, вторая - пляж какой, третья - развлечения, четвертая - дети и т.д. Как это будет использоваться - в форме заполняем все эти данные, а когда будем смотреть инфо по отелям, то информация будет представлена так:

Отель: гуантонама
В номере:
- душ
- телефон
- тапочки (платно)
- ....
Пляж:
- галька
- песок
- ....
Дети:
- няня (палтно)
- дискотека
- .....

Надеюсь теперь будет понятно что тут к чему.
 

yugene

Отошел от дел
Автор оригинала: Xrobak
yugene извини, не уловил ход твоих мыслей - чем это может мне помочь?
Автор оригинала: Xrobak
2) возможно я ошибаюсь, но в данном случае использовать имена этих чекбоксов типа name1...100 нельзя. Объясню почему: сейчас чекбоксов у меня 100, со временем мне нужно будет добавить еще пару чекбоксов, и добавить не в конец таблицы, а к примеру один чекбокс после 35 чекбокса, другой перед 67 и т.п. Т.е. если я задам им имена name1...100, то данные, к-рые заполнялись до этих изменений в стурктуру таблицы сдвинутся.
Можно называть эти чекбоксы так, как удобно для их перебора в массиве. В каком порядке хранить их в БД - вообще не важно. А для того, чтобы "добавить не в конец", как раз и используй дополнительное поле в таблице, описывающей чекбоксы.
 

Xrobak

Guest
до этой темы у меня была такая структура (после обсуждения тут я ее изменю):
Код:
CREATE TABLE `hot` (
  `id` int(4) NOT NULL auto_increment,
  `id_country` int(4) NOT NULL default '0',
  `name` varchar(255) NOT NULL default '',
  `about` longtext NOT NULL,
  `r_bide` char(3) NOT NULL default '',
  `r_seif` char(3) NOT NULL default '',
  `r_24hour` char(3) NOT NULL default '',
  `r_tvsputnik` char(3) NOT NULL default '',
  `r_telefon` char(3) NOT NULL default '',
  `r_termos` char(3) NOT NULL default '',
  `r_tapochki` char(3) NOT NULL default '',
  `r_roomserv` char(3) NOT NULL default '',
  `r_chainik` char(3) NOT NULL default '',
  `t_parikmaxer` char(3) NOT NULL default '',
  `t_parnaya` char(3) NOT NULL default '',
  `t_r_alyakart` char(3) NOT NULL default '',
  `t_r_arab` char(3) NOT NULL default '',
  `t_r_izya` char(3) NOT NULL default '',
  `t_r_turok` char(3) NOT NULL default '',
  `t_r_it` char(3) NOT NULL default '',
  `t_r_sredn` char(3) NOT NULL default '',
  `t_r_mexiko` char(3) NOT NULL default '',
  `t_r_gril` char(3) NOT NULL default '',
  `t_r_fish` char(3) NOT NULL default '',
  `t_r_main` char(3) NOT NULL default '',
  `t_krasa` char(3) NOT NULL default '',
  `t_sayna` char(3) NOT NULL default '',
  `t_trainroom` char(3) NOT NULL default '',
  `t_tenis` char(3) NOT NULL default '',
  `t_turbanya` char(3) NOT NULL default '',
  `t_prach` char(3) NOT NULL default '',
  `t_footbal` char(3) NOT NULL default '',
  `t_fitnes` char(3) NOT NULL default '',
  `t_fotogr` char(3) NOT NULL default '',
  `t_ximch` char(3) NOT NULL default '',
  `b_cot` char(3) NOT NULL default '',
  `b_aerobika` char(3) NOT NULL default '',
  `b_baschild` char(3) NOT NULL default '',
  `b_baschild_otd` char(3) NOT NULL default '',
  `b_nyanya` char(3) NOT NULL default '',
  `b_olypic` char(3) NOT NULL default '',
  `b_razvl_bas` char(3) NOT NULL default '',
  `r_ani` char(3) NOT NULL default '',
  `r_basani` char(3) NOT NULL default '',
  `r_aerobika` char(3) NOT NULL default '',
  `r_luk` char(3) NOT NULL default '',
  `r_sorev_luk` char(3) NOT NULL default '',
  `r_sorev_voleybal` char(3) NOT NULL default '',
  `r_lesontenis` char(3) NOT NULL default '',
  `p_galca` char(3) NOT NULL default '',
  `p_pesok` char(3) NOT NULL default '',
  `p_pirs` char(3) NOT NULL default '',
  `p_matras` char(3) NOT NULL default '',
  PRIMARY KEY  (`id`)
) TYPE=MyISAM AUTO_INCREMENT=1 ;
у меня есть еще одна таблица, точно такой же структуры (в данном случае структуру таблицы привел частично, чтобы не засорять форум), только она содержит всего одну запись, а именно расшифровку каждого поля.
Тут я себе группировал чекбоксы по первой букве с подчеркиванием, например: r_ - это расположение в номере, p_ - это пляж и т.д.

ЗЫ: а за доп. поле всеравно не догнал :( Дополнительное поле на каждый чекбокс использовать? Тогда структура таблицы вдвое увеличится. Или использовать 1 доп. поле, чтобы определять по разделам; пример - 1 соотвествует расопложению в номере, 2 - дети, 3 - пляж и т.п.? Это ты имееш ввиду?
 

yugene

Отошел от дел
Теперь я понял, как ты делаешь :)

-~{}~ 21.04.05 18:53:

Я исходил из того, что у тебя не одна запись на чекбокс, а по одной записи на каждый чекбокс :) Наверное, на твоем месте я бы так и сделал. Отдельной табличкой - список чекбоксов, т.е. для каждого описываешь его номер, название, позицию в списке при выводе на экран (вот оно - поле для сортировки! :)), возможно, какие-то другие характеристики чекбокса. Например, флаг, нужен для него селект "гуд-бед" или нет. В отдельной табличке хранить связи между отелем и чекбоксами. Это ИМХО, я бы сделал так.

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

-~{}~ 21.04.05 18:55:

Соответственно, в той же табличке чекбоксов отдельное поле - "группа".

-~{}~ 21.04.05 18:58:

Увидел у тебя "тапочки (платно)". В табличке связей между отелем и чекбоксами можно сделать поле "платно". Если оно == 1, выводить "(платно)" после чекбокса. Таким образом ты сможешь иметь как платные тапочки, так и бесплатные.
 

Sherman

Mephi
еще раз.

hotel:
hid,...

params:
pid, pgid,...

params_group:
pgid,...

hotel_params:
hid, pid, qid

quality:
qid, qvalue

остальные поля пихаешь туда, куда они относятся, например hotel_title -> hotel и т.д.

p.s. я бы начал с «Введение в реляционные СУБД».

-~{}~ 21.04.05 20:14:

обязатльено не забыть сделать индексы на все внешние ключи, и делать объединения в select в правильном порядке(для mysql критично).
 
Сверху