Re: In an RDBMS, what does "Data" mean?

From: Anthony W. Youngman <wol_at_thewolery.demon.co.uk>
Date: Fri, 18 Jun 2004 18:16:57 +0100
Message-ID: <3pkqxQDJOy0AFw$q_at_thewolery.demon.co.uk>


In message <wekzc.25516$Dh6.9215_at_newssvr31.news.prodigy.com>, Eric Kaun <ekaun_at_yahoo.com> writes
>"Bill H" <wphaskett_at_THISISMUNGEDatt.net> wrote in message
>news:b6tyc.71433$3x.21040_at_attbi_s54...
>
>This is, more than anything, the philosophical divide between relational and
>Pick folks. The more rules, the more they should be kept OUT of the
>application code. "Application" means just that: a judicious application. Of
>what? Rules. Application != definition, just as implementation !=
>specification.

Actually, as a Pickie, I'm very much inclined to agree. Rules should sit BETWEEN the application and the data store. So no, I don't quite agree with the relational approach, but I think the Pick approach is lacking here.
>
>> This is because the business person is much closer to the application
>> and database, and its tools.
>
>Their closeness is irrelevant; they should of course be given tools that let
>them do their job. But encoding the rules in those tools, as opposed to
>having those tools generated from and respectful of the rules, is a big
>difference.
>
>Granted that some rules should be configurable; that doesn't imply that all
>should be. The business, after all, has (or needs!) some structure.
>

Beyond relational's strict data typing, aren't all relational rules configurable? Okay, it's done using constraints, triggers, etc etc but it's still configured by the programmer or dba, as far as I can see.

I want that power in Pick :-)
(Okay we've got it with triggers, but I don't necessarily think that's the best way to do it)
>>
>> As you can tell, a well defined mvDbms application uses the field
>> definitions to describe the data (as it should be) and relationships with
>> other data (or other tables for that matter). Naturally, the field
>> definitions are nothing more than data maintained in the database since
>> they're just data too. :-)
>
>While I see many examples like the above, can you give us an example of how
>the dictionary defines those? What language do you use to define the
>dictionary? Is it user-accessible?
>

I said earlier "the generic trumps the specific". Relational has a rule that says "the data definition must be accessible using the same tools as are used to access the data" (C&D rule 4, my paraphrase).

My multi-value rule 5 - Database self description :-) The database management system shall describe itself using FILEs. FILEs are described by other FILEs. The database itself is described by a FILE. The database shall have no fundamental mechanism to differentiate between FILEs containing data and FILEs containing metadata about that data.

So yes, Pick uses the same language to access both data and definition. And yes, it's user accessible. Because the db engine is forbidden to know that there is a difference between data and metadata.

Which is why I think of a database as layered. And why I find the relational emphasis on "push it into the database" difficult. I see it as a four-layer thing.

Layer 1: the data store.
Layer 2: the integrity layer. Where relational has triggers, constraints, and all that guff. Pick doesn't have anything native here (although a lot of what relational has, Pick doesn't need because the model is different - constraints for example). But Pick really should have a native mechanism here. It hasn't had it in the past because we manage fine without it (really we do - it's just that, in a FEW cases, we can see that relational is worth copying here). Layer 3: the presentation layer. What the apps see - relational tables and views, Pick FILEs. Really, this is where views are defined, so Pick really neither has it nor needs it.
Layer 4: applications - split into 4a database tools and 4b user apps.

I get the impression relational is trying to have a monolithic database layer which is trying to be all things to all men. And if that's the case, it's bound to fail. Break things up into tasks and layers, and don't just have "the database".

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999
Received on Fri Jun 18 2004 - 19:16:57 CEST

Original text of this message