Архитектура рейтинга

[EFL]

Есть таблица с записями из блога.
Любой не зарегистрированный пользователь может проголосовать + или -, 1 раз.
Для этого нужно записывать ip пользователя в БД.

Есть 2 варианта.
1. Создать столбец "votes" в этой таблице и туда вписывать через разделитель ip проголосовавшего.
2. Создать еще одну таблицу (id, post_id, ip) — и уже туда записывать информацию.

Вопрос, который способ правильнее?
Возможное количество проголосовавших до 20 000.

 

[chang]

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

имхо луч так:
для самой записи добавить поле "оценка" куда записывать сумарную оценку

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

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

 

[EFL]

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

1ым способом будет работать через php explode() — in_array()
чтобы дважды не голосовал это тоже будет проверятся средствами php

 

[chang]

ИМХО сверять 20 000 строк при обычном голосовании маразм... особенно средсвами пхп

ради интереса создайте массив на 20 000 IP адресов и найдите в нем айпишник расположенный вначале всередине и в конце ... ну и замеряйте время работы ...

 

[EFL]

ИМХО сверять 20 000 строк при обычном голосовании маразм... особенно средсвами пхп
ради интереса создайте массив на 20 000 IP адресов и найдите в нем айпишник расположенный вначале всередине и в конце ... ну и замеряйте время работы ...

Занимает не больше одной секунды работы(при выводе на 1 странице 20 постов имеем 20 сек), хотя и тестировал на винде.
Я хотел сам все протестировать, но сгенерировать нужного размера таблицу у меня не хватило терпения.
Да и если постов будет к примеру тысяч 5, тех же оценок по 5-10 тысяч, что из этого выйдет?(имею ввиду что это будет за таблица=))

 

[chang]

Занимает не больше одной секунды работы(при выводе на 1 странице 20 постов имеем 20 сек), хотя и тестировал на винде.

1) 20 сек это очень много.... с сайта будут уходить поисковики да и сами посетители. Если не ошибаюсь то в Google Analytics рекомендуемая скорость 2-3 сек (если не меньше)
2) при "статическом" выводе постов их количество не должно влиять на сложность работы алгоритма, в том числе и на скорость ...
при выводе постов на странице не нужно постоянно пересчитывать рейтинг поста ( а судя по скорости сейчас это делается )
рейтинг должен быть заранее посчитан и выводится как простое число .....

Я хотел сам все протестировать, но сгенерировать нужного размера таблицу у меня не хватило терпения.

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

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

таблица будет большая .... 50000000+ записей
но при использовании индексов записи в БД будут хранится в виде дерева, поиск по которому выполняется со сложностью в среднем за O log2(n),
Сложность же поиска IP в строке равна О (N) т.к. они забиты фактически рандомно

итого:
O log2(50000000) ~ 25.5754247590989
O (10000) ~ 10000

естественно это очень грубые прикидки ... и если на хостинге для ПХП выделяется больше ресурсов ( памяти и подобного) а для СУБД меньше ( меньше, в том плане что для "свободного" поиска в таких объемах данных ей не будет хватать ресурсов ) то реализация через пхп покажет лучше результат ....

мое ИМХО: делать проверку силами СУБД ... если начнет сильно тормозить то для теста переконвертировать пару записей для поиска силами пхп ... - если покажет лучше результат то перевести все данные на него, хотя я и сомневаюсь что будет лучше .. но решать естественно вам