Разработка таблицы комментариев - PullRequest
1 голос
/ 15 апреля 2009

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

Как мне это сделать?

Текущие таблицы:

теги, продукты, пользователи, комментарии

edit - это было бы для сайта с несколько большим трафиком, поэтому я не могу заставить его делать все виды сумасшествия: -)

Ответы [ 4 ]

8 голосов
/ 15 апреля 2009

Хотите ли вы иметь комментарии к продуктам, пользователям, отзывам и т. Д.? Или найти продукты, пользователей, отзывы и т. Д., На которые ссылается комментарий?

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

create table join_products_comments (
   product_id int (unique, i.e., one thread of comments per product),
   comment_thread_id int
);

create table join_users_comments (
   user_id int (unique, i.e., one thread of comments per user),
   comment_thread_id int
);

Где comment_thread - это просто ссылка на поток, на который ссылается каждый комментарий:

create table comment_threads (
    thread_id int (PK),
    thread_name nvarchar2(256),
    created datetime
);

create table comments (
    comment_id int (PK),
    comment_thread_id int (FK),
    parent_comment_id int (FK),
    user_id int (FK), -- person who posted the comment
    comment text,
    created datetime
);

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

0 голосов
/ 15 апреля 2009

Лучше всего будет изолировать комментарии от целей. Что-то вроде ...

comment:
    comment_id (PK),
    user_id (FK),
    date,
    comment,
    parent_comment_id (FK)

Тогда таблицы, как ...

product_comment:
    product_comment_id (PK),
    product_id (FK),
    comment_id (FK, unique)

Где только корневые комментарии (без родителей) будут иметь строку. Это позволит вам по-прежнему поддерживать надежную архитектуру с внешним ключом и при этом иметь возможность связывать комментарий только с одним продуктом.

0 голосов
/ 15 апреля 2009

моя попытка:

CREATE TABLE Comment
(
    CommentID               INT            NOT NULL IDENTITY(1,1) PRIMARY KEY
   ,CommentValue            VARCHAR(5000)  NOT NULL
   ,CommentParentCommentID  INT            NULL     --fk to self
   ,CommentParentTagID      INT            NULL     --fk to Tags
   ,CommentParentProductID  INT            NULL     --fk to Parents
   ,CommentParentUserID     INT            NULL     --fk to Users

)

это позволит вам найти их по индексу, без лишних потерь при хранении

0 голосов
/ 15 апреля 2009

возможно

CREATE TABLE comment (
id INT PK,
parent_comment INT NULL FK,
content TEXT,
table_source VARCHAR(30), -- SYSNAME,
row_source INT,
)

В table_source вы сохраняете источник таблицы (продукт, пользователь и т. Д.), А в row_source - идентификатор строки, на которую указывает комментарий.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...