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

From: Dawn M. Wolthuis <>
Date: Fri, 18 Jun 2004 15:43:39 -0500
Message-ID: <cavk63$gm7$>

"Laconic2" <> wrote in message
> "Anthony W. Youngman" <> wrote in message
> news:3pkqxQDJOy0AFw$
> > 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.
> As a relational (as in SQL), I'm glad to see some agreement. But I'd
> yet another opinion.
> Rules should sit both ABOVE and BEYOND the application and the data
> Both the CREATE script for the data store, and the code generation phase
> the application should be able to include rules, when necessary, from
> common rule repository. This rule repository would do for rules what a
> dictionary does for data definitions.
> Or not?

Yes-ish. It is hard to split out metadata, including rules, from data. If a type or a maximum length are designated as binding information regarding an attribute, then those are rules, right? And they are constraints, right? And they are metadata, right? And if we want to store all of our rules for use by a rules engine, these these rules should be there, right? So, what should be in a system catalog or as DBMS constraints specifications outside of a rules respository? Nothing. So, the rules repository should include whatever aspects of the data dictionary are in need of enforcement. The data dictionary is then descriptive for use in queries, not another rules repository. I think of a data dictionary as like a Land's End catalog -- something from which to shop for the information I want.

--dawn Received on Fri Jun 18 2004 - 22:43:39 CEST

Original text of this message