Re: The fable of DEMETRIUS, CONSTRAINTICUS, and AUTOMATICUS

From: Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net>
Date: Thu, 21 Oct 2004 17:45:54 -0400
Message-ID: <jma9lc.ner.ln_at_mercury.downsfam.net>


Laconic2 wrote:

>
> The first thing I want to discuss is the idea behind "system of record".
> This is very old fashioned terminology for a concept concerning data that
> appears in more than one file and/or database. What it says is that, in
> any
> dispute about the "correct value" of any data item, there is one system
> that is agreed to be the "system of record" for that data item.
>
> So if the data item, "Zip Code for Aspen, Colorado" is stored in
> hundreds
> of files or databases, there is one that you can go to for "the
> authoritative answer". The only agent that can override the "System of
> record" is a person with suitable authority. If we don't agree on
> this,
> then we need to discuss it. If we agree here, we can discuss whether
> "metadata" or "DDL" should be the "system of record" for meta-state
> changes. It goes on from there, but I want to see whether we agree so
> far.

Yes, there must be a system of record. In my world it is definitely the metadata, not the DDL.

>
> Second, can we agree that machines aren't responsible for anything? If a
> machine malfunctions, the question of "who is responsible" needs to be
> traced back to human agency. If we disagree here, we can discuss it.

We agree here. Human beings are responsible agents. The hammer did not hit Joe's thumb, Joe hit Joe's thumb with a hammer.

> If
> we
> agree, we can talk about a gray zone, which is intstitutions made up of
> people. By this I mean, companies, corporations, governments, countries,
> schools, etc. Is the institution itself capable of "responsibility" or
> does the responsibility have to devolve on the constituent persons?

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.

>
> Once we gat all that out of the way, we can discuss what the
> responsibilities of the vendor, the dba, the programmer, and the user
> are.
>
> Finally, and this deserves a topic of its own, who is the "user"? This
> is less obvious than it seems.
>
> >

>> 1)  3rd party vendor issues DDL.  Neither vendor(ken) or dba(laconic)
>>     like this, scratch it.
>> 2)  End-user makes change.  Vendor claims this is cheaper than either
>>     vendor or dba doing it.
>> 3)  Dba does it.

>
> The real question isn't who does it. The real question is, "who is
> responsible?"
> (see above).

All parties belong either to the vendor or the customer, so the primary distinction is between those two parties. In these terms, my placement of the allowed salaries into their own table puts salary constraints undisputably on the customer side. If the constraint is in DDL, then the customer is not prevented from changing it, but they incur the cost of specialized staff.

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.

>

>>
>> 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.

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 can I convince you that using the tool will actually give you more
>> control over the database than you have now?  You can do absolutely
>> anything you want to the database.  The only request is that you do not
>> issue direct DDL, but that you give input to the builder and let it
>> generate the DDL, so that it is managed.  The big advantage of this
>> approach to both you and me is that it makes us partners.

>
> We aren't partners: we are client and vendor. Let's get that straight.
> I'm not a partner of Microsoft, of Oracle, of Sun, of IBM or of HP. I buy
> from them. They sell to me.

Thank goodness. Marketroid BS does not come naturally to me.

>
> 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

-- 
Kenneth Downs
Use first initial plus last name at last name plus literal "fam.net" to
email me
Received on Thu Oct 21 2004 - 23:45:54 CEST

Original text of this message