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

Количество полей в таблице

  • Автор темы Автор темы fax
  • Дата начала Дата начала

fax

Guest
Количество полей в таблице

Есть юзер , у него есть >50 линых настроек которые нужно хранить в БД..
И тут только-что на форуме прочитал , что создавать таблицу с кол-вом полей >50 -это неочень хороший вариант , и он не практикуется...
И что тогда делать ?
Создавать множесто таблиц по 10-15 настроек в каждой или есть иное решение?
 
тут только-что на форуме прочитал , что создавать таблицу с кол-вом полей >50 -это неочень хороший вариант
Нажмите для раскрытия...
покажи пальцем, где ты это читал.
тебе объяснят, чего ты не понял
 
http://phpclub.ru/talk/showthread.php?s=&threadid=63579&rand=10

Фанат такой вывод я сделал прочитав твой ответ.

-------
вообще допустимо такое колличество аолей в БД, учитывая что уже 10 есть? Нормально ли это? Практикуют ли так профессиональные РНР-программисты?
(с)BeatBox

-------
нет не нормально.
Нет, не практикуют.
(с)Фанат


Может и в правду я что-то неправильно понял?
 
там совсем другая ситуация.
там 32 возможных характеристики, а не постоянных
 
50 хар-тик это в моем случае , а там если я не ошибаюсь , хотели добавить 30 полей.
И я уже сам понял чего я не понял ......
 
там дело было не в количестве полей.
полей может быть хоть сто, хоть двести - столько, сколько нужно для обеспечения табличной структуры данных.
Двумерной таблицы.
У него же таблица получалась трехмерная.
и он ее собирался эмулировать неправильно.
а ему сказали, как делать правильно.
 
fax

Если настройки = "строки", то удобно делать вот так

Таблица:
USER_ID (INT), NAME (VARCHAR(20)), VALUE (VARCHAR(255))

Для каждого юзера хранишь настройки в нескольких строках таблицы, в поле NAME хранишь "имя" параметра.

Потом считываешь все их в ассоциативный массив. и обращаешься по "имени"

типа

$user_config['param_name']

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

Неудобство опять-же в слишком большой гибкости. Гибкость требует от программиста дисциплины.

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

Фанат
все понятно.
 
совет alexhemp весьма специфичный.
Совсем отдельный случай, навроде того, на который ты ссылку дал.
Для твоего случая не подходит.
У тебя нормальная таблица с нормальными параметрами.
а alexhemp страдает распространенной болезнью новичков - пытается сделать сложно, когда можно и нужно делать просто
 
Фанат

Про новичка ты загнул... SQL я активно использовал уже году так в 94 (XQL под NetWare), когда MySQL и тем паче PHP в помине не было...

Вернемся к нашим баранам - На мой взгляд - 35 полей - значительно сложнее того что я предложил. Большое количество полей в таблице - один из признаков плохого проектирования. Однотипные данные в "строку" не стоит хранить...

И потом, можно воспринимать мое предложение просто как очевидную нормализацию.

Заменим "имя" настройки на суррогатный внешний ключ. И добавим таблицу "описания" или "шаблона" настроек.

ID (INT автоинкремент), NAME (VARCHAR(50)), DESCRIPTION (VARCHAR(255)).

Это удобный на мой взгляд хранить разнородные некритичные настройки. Особенно удобно делать Web-редактор этих настроек, кода совсем немножко :-) И в коде удобно использовать.

А вообще Фанат с тобой беседовать - одно удовольствие ;-) Жалко многие этого не понимают :-)
 
молодец, возьми с полки пирожок.
Все сразу увидели, какоты невфигенно умный.
Осталось только выяснить, с чего ты взял, что у автора данные однотипные.
И что ему вообще имеет смысл углубляться в нормализацию до того, как он сделал первую в своей жизни таблицу
 
Он не описал ПОДРОБНО какие у него данные.
Я ему рассказал КАК МОЖНО делать. А ему решать уже как... Свою голову на плечах тоже иметь стоит...


А тебя послушать - все вокруг идиоты?
 
Войдите или зарегистрируйтесь для ответа.
Сверху