Как организовать схему БД?

Question

[Сергей Протасов]

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

По моему предположению, стоит создать ещё 2 таблицы: comment_question и comment_answer, в которые вынести связи.

Есть ли более грамотное решение?

Comments

[ⓒⓢⓢ]

Добавьте в таблицы Вопрос\Ответ поле [необязательное] id_comment с типом связи один ко многим к таблице Комментарии

[Anton Kuzmichev]

JRK_DV, wat? Как вы себе представляете линковку нескольких комментариев к одному вопросу/ответу?

[ⓒⓢⓢ]

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

В примере поле comment.id - не уникальное.
Например, если будет вопрос (question.comments=3), то в таблице comment.id будем хранить так:
id | text
3 | Первый комментарий к третьему вопросу
3 | Второй комментарий к третьему вопросу
3 | Третий комментарий к третьему вопросу

Можно во всех направлениях вытаскивать данные, и по комменту найти вопрос и для вопроса все комменты одним идентификатором

[Сергей Протасов]

JRK_DV, интересно)
а как отредактировать коммент или лайкнуть, если у него нет uniq id?
В этом случае у нас не получится вообще конкретный коммент выбрать

[ⓒⓢⓢ]

Не совсем вас понимаю в чём именно вопрос.
Я думаю у вас и даты в комментариях будут и прочие плюшки, но нечего не мешает вам добавить необходимые поля.
id, like, timestamp и т.д.

Можно и дальше расширять схему, если необходимо, для таблицы comment сделать связь один ко многим с таблицей (например) comment_history и тут хранить историю редактирования конкретного комментария и это всё будет доступно из таблиц Вопросов и Ответов

[Сергей Протасов]

JRK_DV, каким запросом будем редактировать конкретный комментарий?

UPDATE comments SET text = 'Новый текст' WHERE ???

По каким полям выбрать коммент?

[Сергей Протасов]

По каким полям выбрать коммент?

Answer 1

[Anton Kuzmichev]

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

Если комментарии и к вопросам и к ответам - одинаковая сущность, то я бы сделал их одной таблицей. И в ней 2 поля (помимо прочих):
question_id - связь с вопросом; всегда существует.
answer_id - связь с ответом; NULL если был прокомментирован именно вопрос.
Таким образом, мы можем запрашивать комментарии без необходимости джойнить таблицы, как ко всему вопросу и его ответам, так и отдельно к вопросу, и к конкретному ответу на вопрос.

Answer 2

[artemmityushov]

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