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

In message <eOednaKhM5RQo07dRVn-uA_at_comcast.com>, Laconic2 <laconic2_at_comcast.net> writes
>
>"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message
>news:3pkqxQDJOy0AFw$q_at_thewolery.demon.co.uk...
>
>> 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 offer
>yet another opinion.
>
>Rules should sit both ABOVE and BEYOND the application and the data store.
>Both the CREATE script for the data store, and the code generation phase of
>the application should be able to include rules, when necessary, from some
>common rule repository. This rule repository would do for rules what a data
>dictionary does for data definitions.
>
>Or not?
>
Except I don't understand what you mean by "above" and "beyond". The app sits above the rules, the datastore sits below. In order for the app to write to the datastore it has to go through the rule layer. That's the way I see it. You seem to be saying the rules are somewhere else. I think I see what you mean, but it doesn't make sense to me.

The way I would implement it (in Pick) would be to attach an "integrity check routine" to the FILE. Think of it as a SQL "whole-table trigger" - you can't write to file without setting off this thing (if it exists) and it can reject the write with a "this data is invalid" error.

And as a first thing, I would add the OPTION to make dictionary descriptions prescriptive, so you could enforce eg "this column/FIELD is a number" :-)

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