Re: DB clasical structure violation

cesjr_at_airmail.net (Chuck Schuelke) wrote in message news:<84C55C7779EA0AE0.E73E4A95D37B6A57.586C6F41A6BEB109_at_lp.airnews.net>...
> So clearly you have some non-relational agenda. what database
> overceomes all the problems? If ROLAP is bad what is good?

Yes I do have a "non-relational agenda". It's called "engineering excellence" or "why the hell do PHBs love buzzwords".

Don't forget that Codd and Date think that SQL is crap (and yes, I'm aware that SQL # relational).

Marketing has taught PHBs that "SQL = 42" (apologies to Douglas Adams). With the result that engineers who believe in doing things right get told to rip out working solutions and replace them with the "latest and greatest". The horror stories are legion - Oxford Health Care is one such ... they tried to replace their working Pick system with an Oracle system, and having nearly gone bust in the process they threw out the new system, went back to the old one, and are now doing fine, though much smaller and with an extremely dented reputation...

If people actually *bothered* to do a proper evaluation of the costs, I think they'd be amazed at how expensive relational databases are for what you get. Not the price of the product. No no no. It's the TCO - the cost of maintaining your database, the cost of writing queries for your users, the cost of all those small mods ... for example, I've never ever heard of a full time dba for Pick - it's just a minor duty of some analyst to "keep an eye on the database". That's true for databases so big that Oracle might well require a couple of dba's (mind you, given Pick's frugality maybe that's because the database is much smaller for the same amount of data...). And as I commented below, it's easy (maybe too easy) for end users to maintain their own data...

But as for asking me to recommend "the best database", you're asking me "What's 6 x 9?". There IS NO CORRECT ANSWER. Look at your data. Look at what you want to do with it. Look at what you want it to cost and what you want to achieve.

Pick is programmed using a 3.5GL. You have to work a lot "closer to the metal" than you do with a strictly enforced SQL database. But it gives you a hell of a lot more flexibility. Think C as opposed to strict Pascal, for example.

I think relational, program MV. So if we talk the relational language of entity, attribute, relation, ALL my tables are entities. Every "row" is an instance. All my attributes and relations are stored in the entity table. That's how I achieve integrity. But because relational is a very good theory at the first approximation (Newton's gravity :-) it works very well. I can flex my way round problems, but take advantage of SQL's strength.

And Pick has other advantages - it was designed as an OS, so it takes advantage of OS paradigms, etc etc.

But as I said above, THERE IS NO CORRECT ANSWER. Investigate non-relational dbs. Ask yourself where their strengths and weaknesses lie. Then pick the best tool for the job. Of course, I'd pick Pick every time, but I'm biased :-)

Cheers,
Wol
>
> On 25 Jun 2002 06:42:28 -0700, anthony.youngman_at_eca-international.com
> (Anthony Youngman) wrote:
>
> >Lee Fesperman <firstsql_at_ix.netcom.com> wrote in message news:<3D17D7CD.230C_at_ix.netcom.com>...
> >> Anthony W. Youngman wrote:
> >> >

> >
> >But using MV, it is EASY to design a database that (a) does not
> >contain redundant data, (b) enforces a considerable (if not total)
> >degree of referential integrity, (c) is not 3NF, and (4) kicks the
> >hell out of its SQL equivalent on speed, disk space, maintainability,
> >and cost-effectiveness.
> >
> >The really big problem that MV suffers is that it is simple for users
> >to understand. As a result there are far too many crap systems out
> >there written by users for users. If MS Access is a nightmare for
> >professionals today, so Pick ACCESS was a nightmare maybe 10-15 years
> >ago. But with a pro who can design a database, normalise it,
> >denormalise back into MV, and implement properly, you'll have a good
> >system. And you'll end up with a better system, quicker than with SQL.
> >
> >Cheers,
> >Wol
Received on Wed Jun 26 2002 - 14:47:03 CEST