There is a table in our database that acts very much like a standard lookup table (ID, Description). However, this particular one is not static, the client wants the ability to add entries on the fly. Some entries that will come pre-populated are “special” in that there will be code that checks for them (various business rules).
Normally, I’d create the table without auto-incrementing IDs so I can be safe in the knowledge that the enum that mirrors the entries in the table always match. Then it’s just a matter of checking if this object’s ID matches up with the enum value I’m checking for.
I could attempt the same approach, with IDs that don’t auto-increment and an enum that only covers the entries that aren’t added on the fly. We would shortly run into the issue of coming up with the next ID when the user adds a new entry. Basically re-implementing in code the database’s auto-increment feature.
If I switch to using identity columns, there’d be the whole issue of getting out of sync with the enum values.
Of course I could always match on the textual ‘Description’ attribute but that’s bad for obvious reasons.
Is there a nice way to deal with something like this? This question doesn’t really answer it for me.
In addition to the solutions given here, there is always the possibility to use a completely meaningless identity for all your lookup foreign keys but also have a column which links the lookup to your enum values for business logic:
In this case, the logic is provided and not altered by users. New lookups can even be routed to use any existing logical rules – so you can have different settings which behave the same way as existing hardcoded business rules, but display differently.