Jorge Godoy wrote:
Kenneth Downs <ken@secdat.com> writes:
We went for generating all server-side code out of a data dictionary. This
makes for a significant change in the way change management is handled.
In this scenario change management becomes the analysis of "before" and
"after" data dictionaries. If the changes are all valid, build the code.
Ken, could you explain it a bit better? I think this is an interesting idea.
Sure. To start off I'd say I'm one of those "biz rules belong in the server" guys. My guess is we are on the same page there so we'll take that as a given.
So anyway, some years ago I joined an existing project and was eventually promoted to systems architect. Along the way I developed their change management system from scratch (we had more salary dollars than tools dollars). The "Aha!" moment came when I realized what may seem obvious to many, which was that you can never, nohow, noway, never prove ahead of time that any particular piece of code was not going to break something. You can't even prove it will do what anybody claims.
I wanted a way to know by analysis, just by looking, that any particular change to a spec would work. That is, it would do what it was supposed to do, without stopping other things from doing what they were supposed to do.
It so happens you can have this if you generate your code out of a spec that is itself data. The spec has to be comprehensive, it can't just be columns and tables. You need to be able to specify security and derivations all in one place, that is the only way to specify all business rules in a single place.
There are two major things you can do to make sure a spec is workable before you start generating DDL and triggers.
First, you look for mistakes in the spec itself, such as duplicate column names in tables, references to non-existent tables, and so forth.
Second, you look for mistakes or impossibilities in the delta-spec, the changes to the spec. For instance, if column COL1 is char(7) and the new spec has it listed as INT, you can stop there and tell the person the change is not valid.
Futhermore, you can then do really cool things like generate a report of what *would* happen if you did an upgrade, such as the creation of new tables, changes in formulas for existing columns, new cascades, changes in definitions of keys (added a delete cascade, removed a delete cascade), and then give it to the customer to sign. Ha! I love that one :)
What falls out of all of this for free is that once you have that data dictionary you don't have to code maintenance forms anymore, because a library file can generate any maintenance from from the dictionary description of a particular table.
So anyway, that's the tip of the iceberg on that. Once you go to a dictionary-based generation system, it actually changes a lot of how you do things, not just change management.