Меню
Что нового?

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

que_bunt

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

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

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

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

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

-~{}~ 12.01.07 13:46:

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

-~{}~ 12.01.07 14:02:

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

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

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

-~{}~ 12.01.07 14:33:

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

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