Question

I’ve an .NET app using Entity Framework 4 and SQL Server 2008 R2, where all the Data Access Layer will be managed by the EF4.

I’ve a table for financial transactions: Transactions with a column Status with possibles values: Opened, Released, Verified, Closed. This table will be very accessed all the time for insert, update and read. I need the better performance I can reach on this table.

The standard solution is to create a TransactionStatuses with Id(int), Name(varchar), and make relationship between Transactions and TransactionStatuses.

But now, I’m thinking in a different solution: Create only the Transactions table with a column Status(int) and create a constraint where Status only accepts 1,2,3,4. And, on my app code create a Enumeration with Opened = 1, Released = 2, Verified = 3 and Closed = 4.

It’s the second solution a better alternative from performance perspective?

Answer 1

Either will be fast; a constraint is perhaps easier to check, but databases are heavily optimised to make checking FK violations very very fast.

Given the two, I prefer the FK option from a maintenance perspective

• it is really easy to add a new status row via DML, vs changing a constraint which is (arguably) harder to deploy, requiring DDL
• you get the benefit of other metadata columns if needed – i.e. a description to go with the code, and perhaps soft-delete dates (for removing from the UI, without making old data invalid)

If the data will never change, then either approach is perfectly viable without prejudice.