Hello! I am about to design a one to one message system. What I mean with one to one is that it should not be possible for one user to send a message to multiple recievers. Let me first state what I need id - may be optional with another approach threadId - will be used to group a specific thread fromUserId toUserId fromFolder toFolder createdDate toReadDate - when the reciever of the message read the message toReplyDate - when the reciever of the message replied to the message topic message - text If we first start to play with the possibility of have all these just as they are (in one table). We have some possible performance issues here since we would not know where to place our clustered index. For a query like "select all messages to a specific user in a specific folder", it could look like this: select id, threadId, fromUserId, toUserId, fromFolder, toFolder, createdDate, toReadDate, toReplyDate, topic from messages where toUserId = 10 and toFolder = 1 If we create a clustered index on toUserId, toFolder then everyone would be happy since the query would return the data really quick. But what if we need to have a list of messages that a specific user sent. We would need an index on fromUserId, fromFolder, and preferly that would be an clustered. But since we already have specified a clustered index we need to make a non clustered index and then we will notice that a bookmark lookup will occour that will drain the performance. When we have messagelist we also probably want to read a specific message and the clustered index should be on the id-column so that we can fetch the message-column without a bookmark lookup. Another approach could be to create two tables. Where we place the message-column in its own table so that we can create a clustered index on that. Another approach could be to separate the message on two rows in the message table so that the sent message has its own copy and the recieved message has its own copy. But that would pretty much duplicate the amount of rows in the table. But it would be easier for us to create a clustered index that we could use for any folder. This approach would also create some redundance for example of the topic-column. The solution could look like this. id, fromUserId, toUserId, messageDataId, folder, readDate, replyDate, topic, createdDate where the clustered index span over fromUserId, toUserId, messageDataId, folder There are a millions of possible solutions, but from my criterias, I want you to specify your own solution that you think would be the best. An important thing is also that since this is a message system there is more inserts than the avarage table. I could guess that we have like 5% inserts and 95% selects. That means that the design cannot only be built for selects, we need to have the performance of inserts in our mind to. Thanks!