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

Alexandr Savinov wrote:
> I mean that it is not good idea to have anything centralized
including
> data dictionary or some functionality if it is not a really small
piece
> of data/function.

Centralization is a good thing until you reach its limits. I prefer the Martin Fowler school of thought (at least on this): don't distribute objects. Sell your favorite grandmother first if you possibly can. Embracing decentralization for decentralization's sake is nonsense to be avoided if you can.

> The centralized approach could be called absolutism,
> monumentalism, totalitarism, centralism or whatever other term you
like
> but the idea is that your system has a single center of the universe.

> Suppose that all requests to resolve computer names go to one DNS
> server. This solution is easier to implement, it is more reliable and

> efficient but... only untill you rich some size.

Yes, and I see a huge number of projects jumping into distribution long before that size is reached. And in any event, you're still talking about an absolute authority - you've just spread that implementation over various pieces. Presumably there is a still a single correct answer to a single query?

> After that you need to
> decentralize the system. The same situation is in any large system
> including data management systems. It is already the next question
how
> it can be implemented. For example, can we currently define a
relational
> model within an existing relational model? No we cannot. It is a
defect.
> Can we include a relational model into an existing model? No we
cannot.
> It is a defect.

I don't understand those questions - define or include "within" an existing model? What do you mean?

> We do not have simply a model for that and most people
> do not need this because they are tought to create systems with one
> model where all tables exist in one space where they have equal
rights.

And that's a good thing. If the database is huge, and has to be spread over many machines, why shouldn't the DBMS software manage that, so to the application developer it appears to be one big database?

> Thus when we start a new system we say: let us create a database
and
> then create 10,000 tables in it. It is the same as to say: let's
define
> a procedure considing of 10,000 lines of code. Of course, we have
> various technlogies and solutions for distributing data and functions

> but we do not have a theory for that.

A theory of distribution? You might be right, I don't know. Certainly research indicates that certain sizes of "code chunks" are more easily organized and grasped by the human mind.

> So we normally simply aggregate
> some available solution by using our own hand-made adapters and
connectors.

Agreed, but there are higher-level languages that simply make such hand-cooked patterns unnecessary. Patterns are indicators of language flaws, nothing more; it's ridiculous that such things need to be hand-coded, and as you can see popping up around Java, many "frameworks" reduce such common patterns to (unfortunately XML-encoded) declarations.

• erk