L' Eomot Inversé,

Thank you for the reply.

This was a generic example but a few actual examples would be statuses applied to invoices and shipments, both of which will have a significant amount of data. The uniqueness of the status will be diluted as the table grows and more importantly as shipments and invoices move along through their respective process. At some point 95% of shipments and invoices will move into a final status (Paid, Shipment Delivered) so I would think indexes wouldn't be useful. Queries will be made based on these statuses quite often as will updates to these status will be common.

Yes the statuses won't really grow and there aren't that many of them (1/2 dozen maybe). A tinyint would be a better fit and I copied from a working version but I hastily renamed some of the code for this post (hence the non-working version I posted).

Yes they will need to be joined almost always because it's vital info to know almost every time a request is made.

In regards to duplicate data... If I choose to store a StatusID multiple times in the table vs the actual name, it's still duplicate data (imo).

In regards to the considerations you mentioned about status being applied to just that entity vs a group.. yes these will be specific to just that entity and won't represent a group.

Design woes.... 😀