Re: the relational model of data objects *and* program objects

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Wed, 13 Apr 2005 22:05:24 -0400
Message-Id: <2qv0j2-78a.ln1_at_pluto.downsfam.net>

erk wrote:

> Kenneth Downs wrote:

>> There an important point here.  If meta-data describes user data,

> then

>> change management is the application of a delta-meta-data.  If your

> meta

>> data is true meta-data, meaning rows and columns (XML flames to

> /dev/null),

>> then the delta-meta-data is magically transformed into first-order

> logic

>> and an easily codable sequence of events.   But more importantly, you

> can

>> validate the destination state, and also validate the delta itself

> using

>> very simple constraints, often just using unique and referential
>> constraints.  For instance, you can take a SELECT of column types

> before

>> and after, and look them up in a table of allowed transformations.

> The

>> table would show "from char to text" as OK, but would have no row for

> "from

>> char to int", causing the delta to fail validation with message

> "cannot

>> convert column foo in table bar from char to int".

>
> I think using relations and relational operators against a system
> catelog is an extremely powerful idea - this might not be exactly what
> you had in mind, and there are other options, but it's appealing.

It is exactly what I had in mind :)

The basic idea is this. If tables seem to have no end of good use for business data, why not for programming data?

>

>> But you can never do this with human-supplied code.  There is

> absolutely

>> nothing intrinsic in the code that will give the same level of

> guarantee

>> that you are installing something that will actually work.

>
> Sounds like you're advocating declarations rather than procedural code
> - if so, I agree. While OO has wrapped and packaged procedural code
> (for good and ill), what's needed are predicates and functions
> describing the rules, rather than clumsy operational mechanics
> (procedural code).

Yes, declarations. I think we can stumble through this chain of reasoning:

1. Declarations = propositions
2. Propositions are stored in relations
3. Relations have defined structures

THEREFORE: 4) The search for a declarative vocabulary is the search for the structure of the meta-data tables. Find one and you've found the other.

Because tables are easier for me personally, I defined the structure first and declarations second. An entry from my data dictionary might look like this:

table AddressBook {

 column first_name { primary_key: Y; uisearch: Y; }
 column last_name  { primary_key: Y; uisearch: Y; }
 foreign_key { parent-table: states; }

 ...more...
}  

>

>> Change Managements = Upgrades = Installs = Development
>>
>> They are all the same thing and should be handled by the same tools

> and must

>> be foolproof.  Code is the sore thumb in the picture, it does not

> allow

>> foolproof change management.
>>
>> Hence the need to find a way to replace human-generated code in the

> db.
>
> Agreed. I like Dijkstra's line: "Progress is possible only if we train
> ourselves to think about programs without thinking of them as pieces of
> executable code."

That one I'll have to look up.

>
> - Eric

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)

Received on Thu Apr 14 2005 - 04:05:24 CEST