Кол-во полей в базе данных. Быстродействие

[Spear]

Кол-во полей в базе данных. Быстродействие

Здравствуйте,
сейчас у меня такая проблема:
проектирую БД. Стал такой вопрос:
у каждого пользователя будет ряд параметров (около 20ти), значение которых будет от 0 до 9999.
У большинства многие из этих параметров будут на 0.
Стоит ли делать отдельную таблицу для параметров, например:
user_id | param_name | param_id |value
и если пользовтаель повышает параметр, наример, под номером 12, то в эту таблицу идет инсерт с данными.

Или можно занести все 20 параметров в главную таблицу пользователей, с дефолтным значением 1?

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

Какой вариант стоит выбрать? В первую очередь интересует быстродействие.
Посоветуйте, пожалуйста.

 

[MuXa247]

Re: Кол-во полей в базе данных. Быстродействие

Автор оригинала: Spear
Какой вариант стоит выбрать? В первую очередь интересует быстродействие.

Тогда вариант с 20 полями.

P.S. Вопрос не для этой темы...

 

[Фанат]

Никакой выборки по параметрам (WHERE) не будет.

дядя шутит

 

[Spear]

Тогда вариант с 20 полями

а чем чреват такой вариант?
Мне говорили как-то (непомню кто и где), что нежелательно иметь в таблице мног ополей.
Ведь в сумме получится уже около 35. Не скажется ил это на скорости?
Может быть у меня просто неправильно понятие о быстродействии и скорости работы БД?
Объясните. пожалуйста.


пс
Мне как раз показалось что вопрос теоритический. Извините, если не в том разделе форума спрашиваю.

 

[master_x]

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

 

[Spear]

дядя шутит

ну я имел ввиду, что не будет запросов, которые будут показывать у скольких пользователей такой-то параметр не ноль..или типо того.
Будут просто выбираться все значения параметров WHERE user_id = .....

Ккой посоветуете вариант?

-~{}~ 31.08.05 18:09:

лучший вариант для тебя- 20 полей

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

поэтому-то я и спрашиваю - лучше 20 полей или делать отдельную таблицу для параметров?
Очень не хотелось бы потом все переписывать из-за неверно принятого решения по торганизации БД.

 

[Фанат]

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

вот у тех, кто говорил, и спрашивай, почему

Ведь в сумме получится уже около 35. Не скажется ил это на скорости?

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

Может быть у меня просто неправильно понятие о быстродействии и скорости работы БД?

скорее, у тебя просто никаких понятий вообще нет, не так ли?

 

[Spear]

не так ли

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

правильно определять типы полей в БД,
правильно определять индексы
делать правильный запросы.

пс
Спасибо за помощь! буду делать дополнительные 20 полей.

 

[Фанат]

правильно определять типы полей в БД,
правильно определять индексы
делать правильный запросы.

вот это правильно.

в частности, скорость работы таблицы увеличивается, если не делать полей с переменной длиной (то есть варчар и текст)

 

[Spear]

варчар и текст

а если варчару указать длину? В таблице пользовпателей будет только один варчар - никнейм.
Остальные текстовые поля - в базе акаунтов, анкет и т.п.

-~{}~ 31.08.05 19:23:

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

 

[Rashkin]

вот тут в соседней теме интересная фича прошла. serialize *PHP* называется. Юзая ее можно 20 параметров собрать в одном классе 'Пользователь'. Созданый объект каждого пользователя сохранить в битовом поле в базе, предварительно сделав serialize. в результате в базе 2 поля. но это при условии что Вам не нужна, к примеру фильтрация по одному из 20 параметров.

В противном случае. данные типа SET в общую таблицу, а типа TEXT в другую

*на мой сугубо непрофессиональный взгляд*

 

[MuXa247]

Автор оригинала: Spear
а если варчару указать длину? В таблице пользовпателей будет только один варчар - никнейм.
Остальные текстовые поля - в базе акаунтов, анкет и т.п.

У varchar всегда должна быть ВСЕГДА указана длина! Но это так же тип с не фиксированной длиной. Вместо него юзай тип char

Автор оригинала: Spear
-~{}~ 31.08.05 19:23:

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

Тут уж тебе решать, как ты построишь структуру БД. Минус выноса параметров в отдельную таблицу - это потеря скорости на дополнительную выборку. Плюс - экономия места на диске и большая гибкость...

 

[Фанат]

Rashkin
я одного не понимаю. Зачем вам РЕЛЯЦИОННАЯ база данных?
если вы храните в ней данные, как бомж в чулане - накидав в полиэтиленовый пакет?
И чтобы достать любую вещь, надо вытряхнуть пакет на пол и копаться, отыскивая нужную.
База данных придумана же для МГНОВЕННОГО доступа к любым нужным параметрам.
Для возможности объединять таблицы по этим параметрам.
Для возможности получать статистику по этим параметрам.

И не надо слушать этого лоха, который заявляет, что ему не понадобится обращаться к своим данным по отдельности.
Он ВООБЩЕ ничего не знает о программе, которую взялся писать.
ВСЁ ему понадобится.

Откуда, из какого пальца вы высасываете идею про сериалайз? про полиэтиленовый пакет с мусором в суперсовременном автоматизированном хранилище?
КАКИЕ в этом плюсы? Какие минусы в хранении данных в нормальном виде в бд? Кроме интеллектуальных затрат на проектирование НОРМАЛЬНОЙ бд?
Ну если не хватает интеллекта - так не пользуйтесь базой вовсе.
кидайте свои сериалайзы в файлы с номерами 1 2 3 - и вот вам ваша любимая база.

-~{}~ 01.09.05 10:46:

а что такое битовые поля?

 

[Rashkin]

Ну человек я здесь новый решил поумничать. Бинарные поля Blob'ы. Ну в общим, чтобы много столбцов не было. и если уж у нас статичные данные, то бишь кирпичи. есть такой совет в мануале.

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

это в разделе оптимизация селекта->другие советы. иногда сток всего понасоветуют. ну тем не менее

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

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

а про сериалайз читайти интересная фича на мой взгляд. я из за нее пхп три плюса поставил

-~{}~ 02.09.05 00:51:

Нормальной БД??? это мускул чтоли нармальная БД???

 

[SelenIT]

это мускул чтоли нармальная БД???

Если, как в данном случае,

В первую очередь интересует быстродействие

то (имхо) более чем

 

[Фанат]

я из за нее пхп три плюса поставил

пхп просто обалдел от счастья.

в общем, всё ясно с товарищем. медицина тут бессильна

 

[Rashkin]

Милачка вы популярны, эта ни я папулярна, эта авитаминизация папулярна.

да вы правы. не надо быть семи пядей во лбу чтобы понять хранить текстовые данные в блобах в бд - глупо. это как до пекина раком.