Death To SQL And All Its Children

But isn't normalisation all about coercing information into a format suitable for applying relational algebra? Or do you understand me as meaning converting the data into *first* normal form, which I most definitely DON'T mean! Maybe I've got it wrong, but as I understand it, if your data isn't normalised, then it's unstructured, and you can't apply relational algebra.

> I'd say you are confusing the crap engineering you've seen for relational algebra ;)

Relational algebra is maths - it has nothing to do with engineering ;)

If by "crap engineering" you mean C&D's 12 rules defining what a relational database is, I'd agree with you :-) A relational database, as implemented by C&D, is crap engineering.

That is my point. I can show, from an engineering standpoint, that a post-relational NFNF database can mimic a relational first normal form database and have near-as-dammit identical performance characteristics. I can show that any optimisation you can apply to an RDBMS, I could apply the same to NFNF. So far we're equal. But because NFNF is not constrained by C&D, I can apply further optimisations *at* *the* *engineering* *level* that means NFNF blows relational out of the water.

For example, I've thrown out this challenge repeatedly - "please *store* a list in an RDBMS". Yes it's easy to *model* a list in an RDBMS, but that's just shoved a load of complexity into the database that shouldn't be there! That's why NFNF is a far superior data store. Because it can store a list AS A LIST, it doesn't need to store "position in list" as data in a table (indeed, doing so is not only necessary with a first normal form database, but also extremely bad engineering because you are - from the application's point of view at least - mixing up data and metadata in the same table with no way of telling which is which, other than in the programmer's head!). Another advantage is that it stores the key *once* for the entire list, not once per element of the list! Those two factors mean an NFNF datastore probably needs half or less "real estate" on disk to store the information. Okay - that's irrelevant to theory, but from an engineering POV, reducing the need to read from disk makes a massive difference to the speed - and by being able to cache more data in RAM that difference is amplified!

Basically, as you can see, my point is that you CANNOT implement a relational database, as defined by C&D, without C&D enforcing a whole bunch of crap engineering decisions - if you don't implement those crap decisions then you are not C&D-compliant.

(By the way, I would always use relational theory to design my databases, but I would then put it in an NFNF database precisely so I could optimise it in ways forbidden by C&D.)

(Another aside - NFNF databases don't have query optimisers. A basic totally-unoptimised relational database of any size will have extremely inefficient query performance - basically just a brute-force search of the entire database. An NFNF database can do a hierarchy-search. As a result, if a relational database query engine wastes maybe 10% of its power doing an optimisation, it can make massive gains in efficiency. An NFNF database, on the other hand, only has about 3 to 5% headroom before it hits perfect efficiency, so to achieve any noticeable gain in query efficiency could easily cost 50 - 100% extra. Just not worth the effort!)

Cheers,
Wol