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

Alexandr Savinov wrote:

>> ...and once again in the next layer of the code, as in:
>> 
>> 1)  db layer
>> 2)  web service layer
>> 3)  browser layer

With regard to all technologies: This too shall pass. Today it is the 3-tier web system, tommorrow....? In order to minimize reimplementation costs, you want your assets developed in a data dictionary, not in code.

>

>> This is why the One True Data Dictionary must exist outside of all of
>> them,
>> and be used to implement all of them.   If the spec is both
>> machine-readable and human-readable, mores the better.

Nope. It is a simple recognition that:

1. All business rules resolve to database specifications
2. The other layers need to know what's going on in the database

There are also elements in my data dictionary that are UI-related, such as column ordering, but even these effect multiple layers.

> We
> need a layered system of dictionaries (if we are talking about
> dictionaries) where one layer defines a dictionary which is used in
> another layer and so on.

Nope. Biz rules are implemented in different ways for different reasons in different layers, but they are all the same biz rules, or you don't have an application.

During a build with our system, the data dictionary is loaded in from a text file, used to build the database, and then copied to the web layer in a format that that layer recognizes. The web layer does totally different things with it, but it must of course use the *same* *information*, pardon my language, but WTF else would it use? The web layer also passes javascript to web pages containing the same dictionary, which is again used for different purposes in the UI (making fields read-only, changing formats of phone #'s, that stuff).

> The main difficulty is to get rid of the
> temptation to think using the standard coordinate system (relational
> model, object-oriented programming etc., i.e., what we were taught in
> school and what we are frequently forced to use to be qualified as
> "successful" professionals).

No matter what you call it, the customer is paying for a system that keeps accurate records. That means the database is the first and final concern. In a database app, there is no theory of code that trumps the needs of the database. Rather, as "form follows function", the code theory needs to come after the database theory.

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