More information about the Underscore mailing list

[_] freelance database

Tom Gidden gid at
Wed Jun 5 15:12:00 BST 2002

On Wednesday, June 5, 2002, at 02:48  pm, David Elliott wrote:
> Done it.

cool.. can I see it? =)

> Not true.
> Not True.
> Depends on what you call cleanly

I'll reserve judgement to see whether what you've implemented is the 
same kind of thing as what I was trying to implement.  All I stated was 
that what I was trying to implement was impractical to implement in SQL 
(or more accurately, relational databases).

SWDB was really just one application of the platform I wanted... an 
example of the kind of thing that's hard to do well at the moment, but 
should be trivial to implement with the right tools.

> I think that it all depends on the favour of your SQL server. MySQL is 
> not
> up the the job as far as I concerned. It is OK for pure web work but 
> not the
> stuff that I usually get involved with.

When you need to implement something that does not fit the relational 
model, then the use of SQL is usually as a few sets of massive 
persistent hash tables, OR as a sub-par file system.

Take OODBMSes, for example.  Complete conceptual hack-jobs, IMHO.

Or Oracle's hierarchical extensions.  Total hack jobs, crowbarred into 
the RDBMS model and SQL syntax.

For most of the work I do (on the web, at least), expression of nearly 
all objects and processes as mathematical constructs (such as in 
Haskell), along with a persistent deep data storage hierarchy  would 
make the work a lot simpler.

This is something that SQL doesn't even touch.  The relational model is 
great for tabular data, but a persistent DOM-like model is much more 
useful.  As soon as you have a tonne of optional attributes for a given 
entity (such as 'favouriteColor' -- useful for site customisation, 
carNumberPlate, spousesFavouriteBreedOfCat...) you have to resort to 
key->value assignments as a rule, which cannot be handled particularly 
well in the relational model.

If you're just using SQL to store tuples, then why not use a better tool?

Try modelling a nice deep XML parse tree in SQL -- it's doable, but 
hacky to say the least.


Tom Gidden
Litebase Solutions Ltd.