Re: How to create a DBMS from scratch?

In article <nureuuoiu6quuc8g87cgk6qlbklsbhns6j_at_4ax.com>, Andy Dingley <dingbat_at_codesmiths.com> writes
>On 28 Nov 2002 03:01:15 GMT, Christopher Browne <cbbrowne_at_acm.org>
>wrote:
>
>>The fact that certain varieties of hierarchical queries are not
>>particularly convenient in SQL is a bit of condemnation thereof.
>
>Indeed. I don't think this will happen (legacies being what they are)
>but I can see a potential future where commerical DB's split into OLAP
>(this being what most business clock cycles are now spent on) and
>graph-based triple stores.

Maybe there's a reason for legacies being there ... as for business clock cycles being spent there - are they being spent wisely, or being spent on the latest buzz-words ...
>
>I'm resistant to object stores and OODBMS in general - this tree
>structuring is both restrictive, and pervasive through most of them.
>Oracle 9i is a case in point - my current project is a flexible rich
>media / metadata store, and the Oracle implementation that has been
>suggested is horribly limiting - it's still stuck with this "XSLT
>transforms can fix everything" mentality.

The trouble (or one of them) with SQL is that its proponents believe that it is the 42 of databases. The fact is, the real world does not fit neatly into pigeonholes. And okay, I'm very much a Pick fanatic. But seeing as I work with Pick and SQL, every time I hit SQL I'm frustrated by all the limitations it imposes on me which Pick doesn't.

One of the reasons Pick survives is it does what it does very well. And what it does is model the REAL world, not what narrow-minded people believe the world should be. It's been commented that Pick programmers tend to be far more business-aware than their SQL counterparts. Not surprising, actually, many Pick people slipped into it from business, which is both a strength and weakness. I've commented that Pick is very close to XML, others have implied they think of Pick as an "outdated hierarchical" database, it's often referred to as a "post-relational" database ... and I tend to think mostly relational when programming Pick.

At the end of the day, Pick is flexible. It can pretend to be anything. BECAUSE it FITS the real world. There are a lot of legacy Pick systems. And one of the reasons is that those companies modern enough to replace them usually find that they rapidly succumb to the competition (who haven't replaced their Pick systems ...). There's very few figures available, but the only study I know of concluded that Pick-based businesses typically spent half the amount of money on their databases than companies using other DBs ...

I'm not sure whether Pick would suit you, but it's always nice to hear people who don't believe in being lemmings, and don't believe that favourite is perfect. That said, if you're storing *data* (and not objects like photos, recordings, etc), I've yet to meet anything that beats Pick ... :-)

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
Witches are curious by definition and inquisitive by nature. She moved in. "Let 
me through. I'm a nosey person.", she said, employing both elbows.
Maskerade : (c) 1995 Terry Pratchett