более 50 полей в одной таблице, плохо?

[que_bunt]

более 50 полей в одной таблице, плохо?

здраствуйте!

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

 

[Фанат]

количество полей в таблице - не та проблема, которая должна тебя волновать (с) не помню кто, здесь, недавно.

 

[que_bunt]

понятно, спасибо.

 

[Shturm]

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

Я бы сделал слегка подругому:
Разнести логику хранения данных на три таблицы: список анкет (если она всегда будет одна, то обходимся без нее), список вопросов
(ID анкеты | ID вопроса | Вопрос), и список ответов:
(ID анкеты | ID вопроса | ID пользлвателя | Ответ).

На мой взгляд такая схема будет полезнее.

 

[que_bunt]

я опять на распутии, приблизительно так и хотел сделать, но производительность тут будет ниже наверное...

 

[Shturm]

с чего бы это?

 

[Фанат]

а что - есть основания предполагать проблемы с производительностью?

 

[que_bunt]

количество записей в бд с ответами для каждого пользователя - 50, максимум будет 10000-15000 пользователей, что вообщем-то реально, клиент вроде серйозный, с ЮСА, говорит будет много пользователей.
итак 50Х10000 = 500 000! записей в бд, это имхо уже напряг, хотя с точки зрения нормализации вроде нормально выглядит.
даже если взять что будет например не больше 5000 (тоесть делть на три все что говорит клиент) всеравно много ведь получаеться?

-~{}~ 12.01.07 13:46:

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

-~{}~ 12.01.07 14:02:

подскажите плиз.

 

[Shturm]

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

А вообще нагрузки - это не количество записей, а частота их чтения и модификации. Отсюда следует необходимость сделать так чтобы операции эти (в основном изменение) - проходили меньшей кровью. Разнесение данных по разным таблицам, на сколько я представляю, в общем случае этому способствует.

 

[que_bunt]

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

 

[Фанат]

я как-то не понял связи между заглядыванием в бумажку предложенной структурой.

насколько я понимаю, анкета здесь - не опрос, а нечто вроде профилья пользователя.
и зачем её размазывать по вертикали, я не очень понимаю.

 

[que_bunt]

анкета здесь - не опрос, а нечто вроде профилья пользователя

именно, сорри если сразу не так обьяснил.

-~{}~ 12.01.07 14:33:

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

 

[Фанат]

ну, я считаю, что разницы между этими решениями нет никакой. ну, а привычнее, всё-таки, т а б л и ч н а я структура.

Почему сообщения в гостевой книге по вертикали не записывать? ид сообщения, тип записи, содержание записи
чё бы все базы на такую структуру не переделать?

 

[que_bunt]

спасибо Фанат, спасибо Shturm.