Keeping code readable when using lookup tables - performance versus maintainability

Question

Working on an audit system where possible event types are stored in a lookup table in the database, with GUID primary keys. For various reasons it's essential they're kept in the DB rather than stored in an Enum or something similar.

Currently, mid-task, my code is full of bits that look like this:

if (currentLp.PercentageShare != lp.PercentageShare)
{
    //percentage change audit
    DiaryEvent de = RepositoryHelper.AuditEvent(lp.CilCase_Id, new Guid("56900C62-3164-4111-BAEC-4F102FEF5813"));
    _cilUpdateContext.DiaryEvents.Add(de);
}

The problem with this is obvious - I know that that particular Guid maps to a Type called "Percentage Share Changed", but someone else coming into the code won't, apart from my throwaway comment.

I can think of two solutions to this problem.

The first is to query the DB from the code using a descriptive field to get back the Guid, but that's a big performance hit as this is going to be happening a lot.

The second is to set up a Guid/String Dictionary inside the class which maps to the values in the lookup table, and use that to get the Guids. But that's a big maintainability hit as they list of types is going to change occasionally, and anyone working in the system will need to remember to make sure the two stay in sync.

Which is the lesser evil? Or is there another solution?

Answer 1

why you do not combine both methods?

• At startup, read the Name/Guid pairs from the Db into a memory table
• Then just look them up there
• If needed, implement a task signal which will re-read the Db table, so you can do online updates.

But updates (= changes of meaning) should be avoidable. Hey, it´s a Guid, it´s already unique, so only if you add new audit events, it will be necessary to look into the Db again:

• Or instead of the signal, just look into the Db one more time if you do not find the Guid in the memory table.

It combines speed with Db flexibility.

BR Florian