Re: The fable of DEMETRIUS, CONSTRAINTICUS, and AUTOMATICUS

From: Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net>
Date: Thu, 21 Oct 2004 23:43:36 -0400
Message-ID: <9lv9lc.vdt.ln@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 Thu Oct 21 2004 - 22:43:36 CDT