4 вариант //// платформа Disqus

1

«Оптимизованней» в смысле скорости работы? Наверное третий вариант. Но скорее всего нет смысла так сильно заморачиваться производительностью.

На удивление плохой совет. Зависимость от сторонних ресурсов должна быть минимальна.

Почему она должна быть минимальна? Amazon сервисы норм?

Почему она должна быть минимальна?

Потому что умные люди сумели сформулировать такую вещь как «управление рисками», где взрослые дядьки не одобряют нашпиговывание продуктов большим числом неподконтрольных вам ресурсов, смерть которых прямо сказывается на работе ваших продуктов. Тоже самое касается и CDN для JS библиотек, кнопочек «рекомендую»/«+1» и прочих сервисов, которые тянут за собой всё остальное.

А что про amazon, например? Хоститься самому тоже где-нибудь? Я бы не был столь категоричен.

Если я делаю бложик или небольшой магазин, ничего страшного не будет, если на пару часов отвалятся комментарии. Но зато проект будет быстрее готов, и можно писать на ЛОР или приносить бользу компании где-то в другом месте.

Не знаю, что значит «оптимизованней», но 1 вариант логичнее всего. А если какой-то бложик свой, то правильно Disqus посоветовали.

1

https://en.wikipedia.org/wiki/Database_normalization

Первый. И не забудь PAGEID сделать.

Как всегда все зависит от ситуации.
А вообще да, Disqus хорошее решение.

Если сайт какой то небольшой конторы, а таких большинство, то почему бы и нет? Какие там риски то?

И parent_id

Если сайт не большой, то любой вариант пойдет, а если большой, или по нарастающей, тогда нужно использовать то что попроще, + не забывать про индексы !

</thread>

таблица с пользователями

user_id | user_name

таблица с мета-данными комментариев

comment_id | comment_date_created | user_id

таблица с текстом комментариев

comment_id | comment_text

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

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

comment_news
comment_news_text

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

CREATE TABLE comment_{$category} AS SELECT * FROM comment WHERE 1=2
CREATE TABLE comment_{$category}_text AS SELECT * FROM comment_text WHERE 1=2

таким образом, при поиске комментариев по разделу вам не нужно делать лишнее [c]WHERE category = news[/c] условие, поскольку вы будете делать [c]SELECT * FROM comment_$category[/c]

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

--
с уважением, ваш подкроватный админ локалхоста.

Первый. Но по сути разница будет невелика.

таким образом, при поиске комментариев по разделу вам не нужно делать лишнее [c]WHERE category = news[/c] условие, поскольку вы будете делать [c]SELECT * FROM comment_$category[/c]

То есть лучше нагородить кучу таблиц чем просто в таблицу с комментариями добавить поля category_type (строка, ENUM, число - по вкусу) и category_id (комментарии к какой конкретно новости/фотке/...), на них разумеется сделать индексы ? Что за бред ?

ну и вообще разделение данных на порядки ускорит выборку по ним.

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

2ТС: разумеется первый вариант.

Зачем отделять мета-данные от самих комменатриев? Разве там отношение не 1-1?

Полностью поддерживаю crlam0. Зачем засирать базу данных кучей таблиц, когда вы не можете наперед знать конечное кол-во типов, а ну как их там будет 100+? Вы действительно считаете что, например, 200-300 таблиц с 100к записями обеспечат наилучшую производительность, нежели одна таблица с дополнительным индексированным полем, но с 20-30кк записями? В любом случае, это задачи распределения нагрузки, но никак не проектирования БД. Да и чисто логически поддерживать одну таблицу, куда как проще, чем N-ое, заведомо неизвестное кол-во.

После твоего кода авторизации, давать советы в чём либо - это преступление!

Зарегистрировался что бы поддержать? :D

Именно. Да если честно, давно хотел зарегистрироваться, не выдержал :D

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

ЧТО ЭТО????
оптимизованней для чего? какой язык? где это будет?