The real "truth" of your database schema, and the "sovereignty" over it, resides with your database. The database is the only place where the schema is defined, and all clients have a copy of the database schema, not vice versa. The data is in your database, not in your client, so it makes perfect sense to enforce the schema and its integrity in the database, right where the data is.
The only point missing from the article: an Organic Normal Form™ schema will be, to some small epsilon, immune to schema update modification problems, since tables/columns in normal forms are, more or less, orthogonal. They can be, if one wishes, fully orthogonal, and when so, there exist no side-effects. The re-generated client code will be restricted to the manifestation of such tables. Easy peasy.
Going database first does demand that rogue coders aren't welcome in development. Database first development demands careful thought aforehand, an approach not welcomed by the coding community. Coders want to keep making mistakes, finding them in the debugger, patching. Rinse repeat. There is a better way.
And, there isn't any such thing as impedence mismatch. That's been dealt with here more than once. This is spectacularly true in the java world of actionObject/dataObject. It's a witch hunt.
No comments:
Post a Comment