Re: The fable of DEMETRIUS, CONSTRAINTICUS, and AUTOMATICUS

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

BTW, I don't know what reverse engineering tools the DBMS vendor provided you with. In my case, working with DEC Rdb/VMS the reverse engineering tools packaged with the DBMS were outstanding.

>

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

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

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

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.

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

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

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.

>
> >
> > 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? Received on Fri Oct 22 2004 - 03:51:15 CEST