Re: Pizza Example

> That's fine and we can both recognize that the other has a different set
of
> experiences to bring to any new problem. But my struggle is also
> internal -- what I have seen for TCO does not synch up with what I have
> learned is supposed to provide the best TCO. I advocated for "real
> databases" before I took on leadership of a team doing PICK coding (late
> 80's). At first I tried to get them to think like me and then the light
> went on and I realized how much more productive they were than previous
> teams I had lead.
>
> This is definitely not just a 1NF issue, or retaining orderings, or loose
> typing, or a better query language, but I haven't yet put my finger on
> precisely what it is. It is even possible (though improbable, I think)
that
> what appears to me (and many others) to have provided a much better bang
for
> the buck over the past several decades than the RDBMS's, really hasn't --
I
> don't have enough emperical data to show that it does. I'm still asking
> questions and trying to get a better handle on it.

All right. This provides a much better basis for a free wheeling discussion than the question of whose religion is the true faith. I just wasn't even on the same wavelength as you.

In my previous line of work, people called me in precisely because they weren't getting a "better bang for the buck". But they didn't want me to teach them the true religion. They just wanted their chestnuts out of the fire.

So I adopted these practices that I called "skunk works" in another thread. These are things I would advise any newbie to shun, but that I do, when necessary, to get the job done.

There were two major databases, one in the UK, and one in the US, that were ever so slightly out of whack with each other. So I decided, on a hunch, to compare all the reference tables to each other. It was a little work just to find out what the reference tables were, but I got a pretty good list. Then, I tried to find out whether the values were the same. row for row, across the pond. Well, I got mysterious problems, until I finally compared the domains. One reference table, out of some 600, had been mapped to floating point numbers on one side, and integers on the other side. Wow!

To get all this garbage done in a reasonably short time frame, I ended up crossing (joining, excuse me) metadata with data. If any theorist asked me about this, I would deny it profusely. But it worked!

At another site, I ended up building a data mart just to debug the problems between the operational database and an analysis model that was being built with Cognos. It was practically unfeasable to compare the two databases with each other, but it was easy to compare each of them with a star schema. It only took me an afternoon of reading Kimball, and another afternoon of coding, to get my star schema in shape, with a few errors and omissions. But it took me literally weeks to discover what I needed to know to do the ETL off the operational database. It just wasn't documented anywhere but deep in the code. This was in the nineties, but it might as well have been in the seventies.

So I think a healthy dose of "whatever works" is a good antidote to overextended orthodoxy.

For me, the little engine that is like PICK for you was a critter called "DEC Datatrieve". True database gurus all treated it with scorn, but if you weren't afraid to get your fingernails dirty, you could get a lot done with it!

So I'd love to struggle with you to get a better handle on it. As long as I don't think you're setting a bear trap for me. Received on Fri Apr 09 2004 - 20:05:37 CEST