Re: The fable of DEMETRIUS, CONSTRAINTICUS, and AUTOMATICUS

From: Laconic2 <laconic2_at_comcast.net>
Date: Fri, 22 Oct 2004 10:34:30 -0400
Message-ID: <8eidnSaHOc0eh-TcRVn-oA_at_comcast.com>


"Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message news:9lv9lc.vdt.ln_at_mercury.downsfam.net...
> Laconic2 wrote:
>
> >
> > "Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in
message
> > news:jma9lc.ner.ln_at_mercury.downsfam.net...
> >> Laconic2 wrote:
> >
> >> Yes, there must be a system of record. In my world it is definitely
the
> >> metadata, not the DDL.
> >
> > OK so far.
> >
> > Now, are you saying that if you want to build a new copy of the standard
> > database, you'll go to
> > an existing standard database, reverse engineer the DDL out of it,
and
> > then use that DDL as the basis
> > for creating the new database, or not?
>
> No reverse-engineering. There is a one-way street that goes:
>
> Human being or design tool -> text file spec -> tool -> database
>
> It actually took me years to completely work out the idea that the system
of
> record must exist both in definition and in reality outside of the system
> it governs. If you are building a database you can store a reference copy
> of the spec inside of it, but the persistent store for the spec must be
> outside of the database. It took so long because I tried it different
ways
> and then of course had to make a living with the results of different
> decisions before I could try it a different way.
>
> >
> >> I believe that operationally and legally the institution is treated as
an
> >> indivisible agent, but in order to survive in the real world you have
to
> >> oil all of the parts, as it were. Not sure how this comes into things.
> >>
> >
> > Fair enough. Institution enter into contracts, so it works. And I'm
not
> > sure how oiling all the parts comes into it either.
>
> What I mean by "oiling" is that a successful businessperson does not in
> reality treat the institution as an institution, but takes pains to get to
> know the individuals and work with them. Probably spurious to this
> conversation.
>
> >> You raise a question, just because the customer can do it, does that
mean
> >> they are responsible and must do it? This uncovers an unstated
> >> assumption of my own that if they can, then they must, or they must pay
> >> me time and materials to do it.
> >>
> >
> > It depends on what the contract says. If they contract says your party
> > has
> > agreed to do it, then even if we can do it, we can ask you to do it
> > under
> > the terms of the contract. Where it gets truly messy is if I start to
do
> > it, mess it up, and then ask you to do it right. If the contract is
> > well
> > written, that might require me to roll things back to the last
supported
> > configuration before you start work.
> >
>
> yes, much more sensible.
>
> >
> >> >
> >> >>
> >> >> Speaking entirely selfishly, if I think my code generator is so
> > perfect,
> >> > and
> >> >> it puts the users totally in control, then I will slap a sign on the
> >> >> database that says, "No user serviceable parts inside". Now the dba
> >> >> is recommending against my product and I've lost a sale.
> >> >>
> >> >
> >
> >> > Unless no dba is necessary.
> >>
> > Let's go around on this one again. If you've put the power to do things
> > right in the hands of the user, you have also put the power to do things
> > wrong in the hands of the user. Power and responsibility are
inseparable.
> > I don't see how your code generator can be so perfect that it prevents
the
> > user from doing damage, and yet still leaves the user in total control.
> >
>
> Well put. You cannot ever prevent somebody from doing damage, but you can
> do things automatically to protect them that they may forget to do.
>
> True story. A "team leader" came into my office looking ashen, he was
> passing out of panic into catatonia. I had recently been ordered
> (practically at gunpoint) to have my upgrade tool drop columns, because,
as
> it was explained to me, the programmers knew what they were doing and if
> they removed a column from a spec it should be removed from the table so
> GOLDARNIT DOWNS DO IT NOW! So the team leader was practically crying, he
> had run a patch against a system and his patch caused a column to go away
> that he needed back, bad. Was there any hope? "No problem," I said, just
> look for a table with the same name stem plus "_backup". It contains all
> of the dropped columns and the surrogate key, just put the column back in
> and do an UPDATE from the backup back to the live table.
>
> So you can throw up a lot of warnings, take a lot of precautions, but
after
> that somebody has to take responsibility for pushing the button. I guess
> that brings us back to the contract.
>
> >
> >> I would not say that to the DBA :) But both he and the programmer are
> >> in
> >> trouble. Consider:
> >>
> >> If we agree that there exists a "system of record" for the meta-state,
> >> and determine that it cannot be in the database or in program code
> >> because it governs them, then there are two powerful political parties
> >> who will
> >> instinctively fight it to the death. The programmers and the DBA's,
who,
> >> as it was put so well in Pirates of the Caribbean, are like "two
> >> immortals locked in an epic struggle until Judgement Day", will
suddenly
> >> unite
> >> against a common enemy. The PHB will say, "gosh my programmers and my
> >> dba's both hate it, and they never agree on anything, so they must be
> >> right, cross that vendor off the list."
> >>
> >
> > so how are you going to sell it?
>
> As I always have, directly to those who hold the purse strings.
>
> >>
> >> Thank goodness. Marketroid BS does not come naturally to me.
> >
> > Well, "Partners" sounds like marketroid BS to me. But maybe it's
> > subjective. Maybe one person's meaningful statement is another person't
> > marketroid BS.
>
> I don't slip into it often, but it happens.
>
> >
> >>
> >> >
> >> > Sometimes your
> >> >> changes will be routine, but others may represent fundamental
> >> >> improvements
> >> >> to the system. The builder will export your changes and send them
to
> > us
> >> >> and we can then load them into a test system and learn from them.
> >> >> This is all painless and automatic because we are just handing data
> >> >> around.
> >> >>
> >> >
> >> > What is the difference between data and code? (I think this has been
> >> > discussed in here before)
> >>
> >> I'm going to start another thread on this, but in short:
> >>
> >> Code is recipes. They tell you what to do and you store them in a
filing
> >> cabinet. Data is food, like flour and pies, you store them in the
pantry
> >> and the refrigerator. When this distinction is not understood, you get
> >> paper in the fridge and flour in the filing cabinet.
> >>
> >> Or another example. I can do this:
> >>
> >> CREATE VIEW new_columns AS
> >> SELECT column_id FROM dd_columns
> >> WHERE column_id_existing IS NULL
> >>
> >> but I cannot do this:
> >>
> >> SELECT features FROM file:///BigBunchOfDDL.SQL
> >> WHERE Columns ARE Numeric
> >> AND columns HAVE Constraints
> >>
> >
> > Why not? Doesn't CASE give you essentially this capability?
>
> Perhaps, but the fundamental distinction between code and data remains.
>
> --
> Kenneth Downs
> Use first initial plus last name at last name plus literal "fam.net" to
> email me
Received on Fri Oct 22 2004 - 16:34:30 CEST

Original text of this message