Is it a good idea to remove a Many-Many relationship by doing de-normalization

Question

I have a Message and a Contract, Message is sent with many contracts, and a Contract can belong to several messages. It is not a straight forward many to many relation.

• A contract is having a status. I should keep track of Contract status for each message. Also Contract Start and End Date can be changed based on business logic and each message should have its versions of those values.

• Contract parties is only depending on ContractID, it will not be changed per message.

Thus I made ERD like this:-

Contract

• ContractID
• FirstParty
• SecondParty
• ApprovalDate

Message

• MessageID
• MessageDate

MessageContract

• ContractID
• MessageID
• ContractStatus
• ContractStartDate
• ContractEndDate

The many to many relationship requires more complicated logic. Can I just move Contract columns to MessageContract and remove Contract table? De-normalization principles allows me to do that?

Contract table is only used to hold these three columns, it does not have a relation with other tables except MessageContract and it will require me to select a contract before putting it in MessageContract, and I will do that a lot because I have like 20,000 message per day. I need every processor cycle to get a good throughput. I am just worry about scalability for the case a Contract is having a new relation with a new table. I can't see a reason to put a new table, but what if the system is live and I just need to add a new table. I mean what is the good practice for this case.

Answer 1

With 20k messages/day I think your laptop can bear this workload. Don't worry too much about performance in this low-demanding regime.

Keeping data normalized has many benefit including faster writes and less risk for bugs.

Also Contract Start and End Date can be changed based on business logic

Inlining the contracts table would force you to update those dates in many places. That is more dev work, slower and more potential for bugs. This is the prime argument for normalization.

I am just worry about scalability for the case a Contract is having a new relation with a new table.

Adding a new relation with contracts will make a normalized approach even more attractive. You don't want contracts data to be inlined into multiple other tables.

Denormalization is also a valid technique but I don't think it applies to your case.

I recommend that you start with a normalized data model, index it well and do a quick performance test. You'll likely find that everything is fine.