How to help keep track of identifiers used both in the application and in the database?

Question

For example:

1. I have an ACL (access control list) with keys in the database like create_user and allow_booking_for_past_dates. Each ACL entry has a corresponding method or function name in the application.
2. I have several 'controller' classes for a web application each of which may have one or more references in a 'pages' table in the database.

In both cases whenever a change is made to the application, someone has to remember to update the database and vice versa. Updating the application after a database mod can be relatively pain-free by naming the keys such that they can be easily found by search-replace. Finding instances of an identifier in the database can be similarly pain-free.

Everything else usually is either contained completely in the application (sub-classing, configuration files, etc) or entirely in the database (primary keys, foreign keys, indexes, etc).

How to keep track of these identifiers that bridge the two domains?

We currently have a Word document (of all things) with a table neatly describing the key name, where to find it and a description of what it is. This seems to work better than the "commit it to the application, create the entry in the db and cross your fingers for the future" approach.

Answer 1

You are dealing with the pain of violating a design principle:

Make decisions in one place.

If the access control list and the methods in the application duplicate the same knowledge then changes to that knowledge can't be controled in one place.

Your current solution is to create a third place to control that knowledge. This is madness.

You might be thinking the word document's job is to be the authority. Everything else must conform to it. Bah! You can't compile and test a word document. The most you done here is create a soon to be out of date report on the state of the code.

I could go into a stop gap measure where you generate code from the ACL making it the authority but this is crazy as well.

Really what you need to do is realize that the ACL isn't behavior. It's data. You should be passing the entries in the list to methods that do what the entries need done.

Do that and you can stop messing with your code every time a new entry needs to be added.

Alternatively, if you feel you must have hand crafted methods for every entry then at least handcraft creating the keys in the database. Check the key exists before using it, if not create it. If that becomes a performance issue simply cache the knowledge that the key exits in the DB.

I prefer the ALC-is-data approach. It's simpler. But most importantly these last two ideas make one place the place to decide what the ACL should be.