Re: Lessons

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Wed, 14 Feb 2007 01:17:18 +0100
Message-ID: <45d25501$0$336$e4fe514c_at_news.xs4all.nl>


JOG wrote:
> Bob Badour wrote:

>>> What lessons have you learned that you might want to relay? (Please >>> enumerate.)

Having been plonked by Bob for "intellectual dishonesty" - as usual with his chilling twit filter habits no rebuttal chance whatsoever - I don't feel invited to this game of his. Yet I see some interesting points here, I hope you do not mind me butting in.

> Heck, why not. With the all-encompassing caveat that the follwoing is
> all off the top of my head:
>
> 1. Implementation != Theory
> 2. To produce good IT we should be analysing _Information_ not just
> Technology.
> 3. Value based addressing.is superior to OID's.

OID only works if either

> 4. Values should never be hidden.

I'd call the "in general" qualifier
(some stuff really is and should be private).

> 5. Propositions are simply true or false and do not 'change'.
> 5. OID's break liebniz equality.

I plead ignorance. If you'd care to elaborate appreciation goes your way.

> 6. Encapsulation has a negative impact on shared data, leading to
> query bias.

Information hiding (which is the purpose of encapsulation, e.g. http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html ) is a very useful criterion when determining the boundaries between software/hardware modules. Data management requires a different approach. I have never had a tough practical decision between hiding or sharing data, though. I submit/conjecture that this is no coincidence.

Religious following of any design principle will lead to disaster. In casu chasing encapsulation for data structuring kills data manageability.

> 7. Query neutrality is important for good management of shared data.

Very undervalued insight. Please continue sharing it (exception to the "No 'me to's " rule of Usenet dialectics :-).

> 8. Do not confuse conceptual/physical/logical layers.

Intuitively, yes. However, defining them is a non-trivial task.

> 9. Purely Navigational Databases are inferior to Declarative
> Databases.
> 10. Nulls are both nonsensical and generate logical errors.
> 11. There are two types of updates masquerading as one - domain
> redefinitions/proposition replacement,
> 12. RM redefines some mathematical concepts - tuple/relation/cross-
> product.
> 13. Semi-structured data has no definition.

Currently, yes. The burden, however, is on the theory. Part of the task of managing data is providing structure for data. If this task needs a revolution it requires heroes/artists. If it is ever to be done by an artisan we need grades and assessment of structured-ness.

> 14. Keys are not entity identifiers, nor vice versa. Keys are the
> antecedents of material implication.

? ("material")

> 15. Surrogates are still attributes, just unobserved ones.
> 16. Combining XML with xlink and xpath to create a data model is like
> grafting arms and legs on to a hamburger.

[snip Bob's answers and the rest of the questions] Received on Wed Feb 14 2007 - 01:17:18 CET

Original text of this message