Обзор схемы SQL Server

Question

Я создаю веб-приложение MVC, которое поддерживает различные типы сообщений между пользователями.Например, некоторые сообщения связаны с запросами предложений, в то время как другие сообщения связаны со счетами.И нас могут попросить поддержать другие типы сообщений в будущем.

Итак, вот схема, которую я придумала до сих пор.

MessageThread

Id                 int              PK

Сообщение

Id                 int              PK
MessageThreadId    int              FK
UserId             uniqueidentifier FK
Subject            nvarchar(250)
Text               nvarchar(max)
DateCreated        datetime

RFPMessageThread

RFPId              int              PK/FK
MessageThreadId    int              PK/FK

InvoiceMessageThread

InvoiceId          int              PK/FK
MessageThreadId    int              PK/FK

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

Любые предложения, рекомендации, критические замечания?

Answer 1

Это классический вопрос о шаблоне наследования таблиц, и существует 3 устоявшихся решения:

• Наследование бетонного стола
• Наследование в одной таблице
• Наследование таблицы классов

У каждого есть свои плюсы и минусы. Вы пошли с наследованием таблиц классов, что обычно делают большинство разработчиков, поскольку оно следует модели проектирования кода и выглядит нормализованным. Но это хуже, так как требует частых объединений, вставки и обновления стоят дорого, а обеспечение целостности данных является сложным. Я очень предпочитаю модель наследования одной таблицы: одну и только одну таблицу, [Messages], за ее простоту и производительность во время выполнения в наиболее частой схеме доступа (например, показать, что мой «входящий» - это простой и быстрый запрос). Я рекомендую вам провести некоторое тестирование с предложенной моделью, под нагрузкой и с достаточно большими наборами данных.