как рациональнее хранить инфу в базе?

[_Leonchik_]

как рациональнее хранить инфу в базе?

есть список катологов (до 500). таблице catalog (id_cat, name)
юзеры (бесконечность) выбирая каталоги (чекбоксы) сохраняют по кнопке(Save) id из таб. catalog в таб.
user_catalog(id, id_cat, id_user)
и так для каждого пользователя.

Задача состоит. что бы в следующий раз, когда чел посмотрит на свои выбранные каталоги (видит весь список и с отмеченными его чек.боксами) мог их подправить(добавить чекбоксы. или снять их) с последующим сохранением.
Интерфей того требует, что-бы кнопка Save была Save . а не отдельно кнопки на добавить. и отдельно удалить. тот или инной объект из списка.

на даный момент при сохранении сначало убиваю все его раннее выбранные каталоги, а после сохраняем выбранные. т.к. не известо. что он именно делал(добавлял. или удалял тот или инной чекбокс)

таким образом, id(int 11) таблицы user_catalog(id, id_cat, id_user) очень быстро увеличивается, и может быстро наступить его предел. или быстродействие упадет, т.к. что быстрее будет работать (значения 1-1000 или >~100000)?

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

Хотел узнать как лучше? не скажется ли большие значения в ключе id?
Или лучше при сохранении помучать базу. дабы после жить спокойней?

 

[Alexandre]

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

можно, но так сложнее
удалять - только те записи, были изменены и в которых чекбоксы checked = false
вставлять только те записи, были изменены и в которых чекбоксы checked = true

Вообще проблем с местом таблице не должно быть, так как кол во записей всегда должно быть не больше N * m
N - кол-во юзеров
m - кол-во состояний (отображаемых чекбоксов)

 

[_Leonchik_]

Alexandre
- попробую. все таки лучше это сделать 1 раз при сохранении. чем потом надеятся на удачу

Спасибо.

-~{}~ 23.01.07 18:55:

а лучше xAJAX наверить, и обрабатывать сразу клики.

 

[Alexandre]

чем потом надеятся на удачу

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

 

[asm]

Я бы сделал так:
в табл. user_catalog(id, id_cat, id_user)
добавил уникальный индекс на (id_cat, id_user)

и при save вставлял при помощи INSERT IGNORE все чекнутые категории а потом DELETE WHERE NOT IN(все чекнутые);

 

[_Leonchik_]

asm - гениально! только вот я, ни разу не юзал подобные вещи (INSERT IGNORE) (WHERE NOT IN) - заодно и поднатоскаюсь.

только зачем добавлять уникальный. если он там есть user_catalog(id, ...), или я не допонял Вас?

 

[asm]

ALTER TABLE `user_catalog` ADD UNIQUE (
`user_id` ,
`cat_id`
);

я про индекс. Если есть то гут.

 

[Фанат]

id(int 11) таблицы user_catalog(id, id_cat, id_user) очень быстро увеличивается, и может быстро наступить его предел

можно узнать - как быстро, по твоим предположениям, наступит этот предел?

быстродействие упадет, т.к. что быстрее будет работать (значения 1-1000 или >~100000)?

объясни, пожалуйста, механизм этой быстроты?

 

[Rammstein]

Мб сериализация прокатит? Или край нужно всё по отдельным записям?

 

[Alexandre]

таким образом, id(int 11) таблицы user_catalog(id, id_cat, id_user) очень быстро увеличивается, и может быстро наступить его предел. или быстродействие упадет,

в таблице user_catalog(id, id_cat, id_user) поле id НЕ НУЖНО.

-~{}~ 24.01.07 10:33:

а лучше xAJAX наверить, и обрабатывать сразу клики.

Чем лучше - только нагрузку увеличишь...

 

[_Leonchik_]

Всем привет. рад что Вы все откликаетесь.
по порядку:
Фанат - я предпологаю, что это 'быстро' наступит, если каждый чел будет себе выставлять(выбирать) все каталоги(более 500), А позже поймут. что подобное колич. им не надо. и будут редактировать (удалять не нужные) свои профайлы(каталоги), и тем самым я удаляю его старые 500 штук, и сохраняю новые (пусть даже меньше половыны). И так будет каждый юзер. С каждым челом мой инкремент(ключ) id из таб. будет увелич (быстро). на достачное значение.
Но как подсказывает Alexandre - этот ключ лишний, и действительно. (я пока его нигде не юзаю, и скорее всего он мне не нужен.) Таким образом ответ на Ваш вопрос (объяснить с моей точки зрения механизм этой быстроты?) - излешен. Но, если предположить. что данный ключ нужен был-бы. то все-же лучше хранить меньшие значения. Они меньше в объеме, меньше памяти 'жрут'. но это всеголишь мои догадки.

Rammstein - это если я Вас правильно понял, хранить даные не по отдельности, а ввиде строк? Если да, то мне надо будет выводить на др. странице всесь список, + согласно уже отмеченным раннее пользователем выбранных каталогов + много еще чего.
Поэтому не вижу как мне это сделать. если даные будут ссериализованные.
Alexandre - поле id НЕ НУЖНО - вот это и правильно. Убью!
только нагрузку увеличишь - нагрузку на что? Я вас тут недопонял.
Всем спасибо. Перечитаю еще раз Ваши посты, и приму оптимальное решение для своей задачи.

 

[Rammstein]

_Leonchik_
Если собирать какую-то статистику по всем пользователям, то действительно неприемлемо. НО если эти данные используются только конкретным пользователем, то это получится даже быстрее чем в БД.

-~{}~ 24.01.07 16:12:

только нагрузку увеличишь - нагрузку на что? Я вас тут недопонял.

Каждый клик по чекбоксу = запрос к сервер => нагрузка на сервер

 

[Фанат]

я предпалогаю, что это 'быстро' наступит

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

Но как подсказывает Alexandre - этот ключ лишний

Никто не спорит с тем, что этот ключ лишний.
вот только с тобой, как с одним предыдущим оратором, который тоже решил проблему не тем способом, которым сначала хотел, ОСТАНЕТСЯ одна проблема. Ты, как не понимал элементарных вещей, и заменял знания безумными фантазиями - таки и будешь дальше.

попробуй ПОСЧИТАТЬ, через сколько времени у тебя наступит этот предел. понимаешь? Не фантазировать, а посчитать.

Таким образом ответ на Ваш вопрос (объяснить с моей точки зрения механизм этой быстроты?) - излИшен.

Я считаю наоборот. Для тунеядца, который не хочет ничего знать и учиться - да, излишен. Для человека, который хочет как-то хоть немного увеличить свои знания - ответ на этот вопрос НЕОБХОДИМ.
Здесь, в этом конкретном вопросе - излишен. А если будет другая задача, в которой от идентификатора не избавиться? Опять будешь позориться, задавая дурацкие вопросы? Показывая, что предыдущая проблема НИЧЕМУ тебя не научила?

все-же лучше хранить меньшие значения. Они меньше в объеме, меньше памяти 'жрут'. но это всеголишь мои догадки.

это не догадки а глупость.

 

[_Leonchik_]

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

-~{}~ 24.01.07 12:38:

решилось удалением id из таблицы.

 

[Фанат]

а ты предположи САМЫЕ максимальные реальные значения для всех параметров. и посчитай. слабо?

 

[Rammstein]

_Leonchik_
Это вполне реально посчитать если знать контекст... А у нас третий глаз ещё не открылся.

 

[Фанат]

пусть пользователей будет сто тысяч и сохранять свои параметры они будут 10 раз в день каждый.
твой ответ?

 

[_Leonchik_]

Фанат
100000 пользователей.
500 каталогов.
10 раз каждый все 500 шт.
Итого на 1 день: 100000*500*10 = (последний ID будет) 500000000 на один день. (не большое ли оно?)

на 10 дней: 500000000*10 = 5000000000
месяц? год?
Rammstein - ага!

-~{}~ 24.01.07 14:07:

если бы на данном форуме сохранялись бы все просмотры каждого топика каждым юзером. И при выводе очередного топика для данного юзера надо было бы проверить :
а не смотрел ли он уже его? смотрел? когда? показать? нет? показать только то что он еще не видел? и т.д.
Каким бы был бы последний ID записи сохранения топика?
Посчитаешь?

 

[Фанат]

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

 

[Alexandre]

только нагрузку увеличишь - нагрузку на что? Я вас тут недопонял.

Нагрузку в запросах как на сайт, так и на серввер БД,
представляешь я в течении сеанса по два раза прочеканю или отчеканю часть чекбоксов... каждый чек(анчек) - это обращение к серверу (INSERT или DELETE), т.е. вместо 500 чеков для одного пользователя у тебя будет в среднем 700 или более.