Jonathan Wood
Jonathan Wood

Reputation: 67195

SQL Server Schema Review

I'm building an MVC web application that supports different types of messages between users. For example, some messages are associated with RFPs, while other messages are associated with Invoices. And we may be asked to support other message types in the future.

So here's the schema I've come up with so far.

MessageThread

Id                 int              PK

Message

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

This should work but I question if this is the best route. Obviously, if I only had one message type, I could eliminate the MessageThread table.

Any suggestions, recommendations, criticisms?

Upvotes: 0

Views: 238

Answers (1)

Remus Rusanu
Remus Rusanu

Reputation: 294227

This is the classic Table Inheritance Pattern question and there are 3 established solutions:

Each one has pros and cons. You went with the Class Table Inheritance, which is what most developers tend to naturally do as it follows the design model of the code and it looks normalized. But is the worse performing, as it requires frequent joins, inserts and updates are expensive and the data integrity enforcing is complex. I much favor the Single Table Inheritance model: one and only one table, [Messages], for its simplicity and runtime performance in the most frequent access pattern (eg. show my 'inbox' is a simple and fast query). I recommend you do some testing with your proposed model, under load and with reasonable large datasets.

Upvotes: 3

Related Questions