дизайн базы личных сообщений

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

Первый дизайн представляет собой таблицу для сообщений и таблицу для комментариев к сообщениям:

Message
---------------
id
recipientId
senderId
title
body
created_at

MessageComment
---------------
id
messageId
senderId
body
created_at

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

Message
---------------
id
recipientId
senderId
messageId
title
body
created_at

Я хотел бы услышать ваше мнение!


person tamir    schedule 08.08.2011    source источник


Ответы (3)


В этом случае я бы проголосовал за один стол.

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

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

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

person Jay    schedule 08.08.2011

Использование одной таблицы является наиболее выгодным.

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

person Tyler Clendenin    schedule 08.08.2011

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

person IROEGBU    schedule 08.08.2011