Re: Some Laws
Date: Thu, 23 Sep 2004 04:33:45 -0400
Message-ID: <hrKdnYAUm9kaF8_cRVn-sg_at_comcast.com>
"Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message
news:mg6sic.v23.ln_at_mercury.downsfam.net...
> 3) Big Idea #1. Present the proposal as table layouts and column
> definitions. This has the extremely nifty twin benefits of being
> comprehensible to the client and *provably* *correct* when
> delivered.
For simple systems, the difference between an ERD and table layouts is probably not worth discussing.
For very complex systems, and ERD with attributes and domains, is probably
a useful intermediate step
on the way to table layouts. As far as automating the conversion of an ERD
into table layouts, products like "Data Architect" can be helpful.
>
> 4) All revisions and change orders are cast as changes to the table
> layouts or column definitions.
>
> Actual answer to your question:
>
> 5) Big Idea #2. Now I have to make all of those tables, maintenance
> forms and so forth; I actually have to earn the money by doing
> some work. The thread on "Specifying all Biz Rules in Data"
> lays out the answer, but I'll restate here. If the spec is
> reduced to table layouts, and the work of making a system out of
> the spec is routine, then that process could be automated, simple
> as that. Do this with some type of Data Dictionary and Code
> Generator/DB Builder.
Again, automating the work needed to create the database, once you have the
table layouts can be helped with
products like "Data Architect".
As far as "printing a pick ticket" goes, I just don't get it. This is
where I fail to follow you. Beyond selecting the data you need and putting
it on the ticket, what other work do you have to do? I'm sorry for being
so dense.
Even there, products like DA will convert the model into a Java "case use"