简体   繁体   中英

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?

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.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM