[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Голосование за коммент
Страницы: 1, 2
REZzANATOR
Добрый всем день.

Прошу помочь советом, хочется найти оптимальную реализацию.

Нужно сделать оценку комментов типа (+ 0 -) для зарег. пользователей.

Есть разделы сайта (к примеру статьи, новости и тд). Для них реализован один скрипт CRUD комментов (под каждый раздел заведена таблица типа commentArticle, commentNews и тд) и скрипт выполняет одни и теже действия только в разных разделах с нужными таблицами.

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

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

Как я вижу способы:
- Выносить в отдельную таблицу все логи. Чревато тем что, при большом объеме комментов в разделах, будет долго происходить поиск(хотя если сделать индексы то может не совсем долго) .
- Создавать еще N таблиц под каждый раздел, типа commentLogArticle, commentLogNews и тд (думаю не очень верно)
- Можно сделать кэш в котором хранить голоса (этот способ мутен для меня)

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

Заранее благодарен.

_____________
Valick
Выносить в отдельную таблицу id_comment | id_user

_____________
Стимулятор ~yoomoney - 41001303250491
REZzANATOR
У меня разделов в которых есть комменты сейчас 5.

В отдельной таблице должно быть

commentId | userId | section

где section - это раздел в которм был коммент.

Так вот, из 5 разделов складировать в одну таблицу записи, она ооочень разрастется и поиск по ней может занимать время. Хочу "заглянуть в будущее" и заранее подготовится

_____________
Invis1ble
либо commentId делать уникальным в рамках всех разделов, либо делать разные таблицы "логов" для каждого раздела

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

Valick
Цитата
либо commentId делать уникальным в рамках всех разделов

плохой вариант, да и 5 таблиц для коментов, тоже мягко говоря хреновый вариант
___
ТС хочешь знать как сделать "одну" таблицу для коментов и что бы она не разросталась, спроси меня как (не гербалайф)

_____________
Стимулятор ~yoomoney - 41001303250491
Invis1ble
Цитата
плохой вариант
REZzANATOR
Цитата
да и 5 таблиц для коментов, тоже мягко говоря хреновый вариант


Идентичный вопрос - почему?
Есть более оптимальное решения для работы с комментами из N кол-ва разделов?

_____________
kaww
Цитата
Идентичный вопрос - почему?
Есть более оптимальное решения для работы с комментами из N кол-ва разделов?

Как вы и предложили ввести дополнительное поле section (для таблицы комментариев), т.к. ваше решение тяжело поддерживать. Что если количество разделов будет расти, нужно выводить общую ленту комментариев либо искать по ним или еще что-то?
Invis1ble
обожаю неаргументированные заявления smile.gif ну ладно, раскрою более полно свои мысли
как мне видится - есть 3 варианта:
1. создаем 1 таблицу comment_id, section_id, user_id с соответствующими индексами (по сути, предложенный вариант ТС в первом посте, как я понял)
2. создаем 1 таблицу comment_id, user_id, при этом comment_id делаем уникальным, что требует реорганизации таблиц с комментами в одну и comments.id - primary key.
3. создаем для каждой из таблиц с комментами свою табличку (articles_votes, news_votes и т.п.) - comment_id, user_id. Если таблиц (разделов) не много, то вариант вполне имеет право на жизнь
Какой вариант выбрать, зависит от ряда других факторов.

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

Valick
Угу, комментарии это сущность, одна сущность - "одна" таблица.
Вторая таблица - это архив.

Почему плохо 5 таблиц? да я уже вижу 7 джоинов в запросе, либо 5 отдельных запросов с двумя джоинами, если вы чуть хитрее.

почему плохо делать уникальный столбец для 5-ти таблиц? а кто будет следить за уникальностью? можно конечно использовать суррогатную таблицу для формирования уникального id а потом раскидывать его на 5 таблиц, но это мягко говоря через жопу.
___
скоро на вопросы почему, будет проще отвечать читайте книги smile.gif

_____________
Стимулятор ~yoomoney - 41001303250491
Invis1ble
см. коммент выше

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

REZzANATOR
kaww, Valick
Цитата
Как вы и предложили ввести дополнительное поле section (для таблицы комментариев), т.к. ваше решение тяжело поддерживать. Что если количество разделов будет расти, нужно выводить общую ленту комментариев либо искать по ним или еще что-то?


Общей ленты комментов не предвидится. Смысла в ней пока нет, да скорее всего и не будет. Лента показывается для данного раздела(В статьях показываются комменты по статьям и тд).

Самая явная пока проблема с N таблица комментов для разделов - это выборка последних комментов пользователя (по дате).

Вот тут всплывает карявость подхода.

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



_____________
Valick
Цитата
А если более точно по поводу вашего предложенного способа - это тоже будет адовая таблица из которой выборка будет оооочень долгой.

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


_____________
Стимулятор ~yoomoney - 41001303250491
REZzANATOR
Valick

[quote]уверены? ну дело ваше[quote]

Ну Вы представьте, проект который имеет среднюю посещаемость и в среднем оставляют 200 комментов в день - что будет с такой таблицей через месяц? а через полгода? куда потом бежать с таким жанром и с такими героями?

_____________
Valick
Цитата
куда потом бежать с таким жанром и с такими героями?

скорее всего в библиотеку за книгой по MySQL, судя по всему вы плохо представляете её возможности...

_____________
Стимулятор ~yoomoney - 41001303250491
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.