Re: What does this NULL mean?

"Alfredo Novoa" <alfredo_novoa_at_hotmail.com> wrote in message news:1134734448.221514.219890_at_g44g2000cwa.googlegroups.com...
>>> What I mean is that they don't have significant differences. The
>>> catalog is a database like any other and we already have excellent
>>> (theoretical) tools to manage databases.
>
>>The significant difference is that one deals in static databases
>>and the other in the dynamic change and evolution applied to
>>databases as a result of application development.
>
> Catalogs might evolve with the DBMS, so it is again the same.
>
>>You may like to perceive database systems change management
>>as a very simple issue, however I do not.
>
> To me it is essentially the same as source code change management, but
> a lot less frequent.

Frequency is directly related to the scale of operations under consideration, and how the chunks of change are implemented.

Source code change management is one consideration, while another is the corresponding schema changes, which may or may not imply a sequence of physical data conversions and/or the loading of new data sets. There may be other considerations.

Complexity is invariably introduced when one commences the task of coordination between each of the above parallel considerations.

> All the schema evolution should be represented in the database log. We
> could to move in time to where we want and to have a perfect view of
> its evolution.

The schema evolution, as you note above, needs to be invariably heavily coordinated with the source code evolution (ie: application development). While the data changes may so be logged, neither the source code changes, or the coordination between the two are yet provided for by services within the database system.

>>It is the single most
>>expensive issue in the IT management environment, once the
>>scale of the system exceeds a certain "simplicity threashold".
>>Expensive in terms of time and revenue.
>
> But this would be a practical problem, and not a theoretical one.

The only reason you do not classify it as a theoretical problem is because the model you use for database systems is the 30 y/o relational model which has not evolved in all that time, and which does not address the issue of either the database application software environment, or change management.

Date covers the (relational) database application software environment by means of a small diagram in the introduction to his works.

As I have been saying for some time, the relational model of the data is incomplete as a database systems theory for this century because essentially, things have changed. See: http://www.mountainman.com.au/software/history/relational_model_incomplete.htm

> Theoretically, it is a completely solved issue, but current tools are
> light years far from the theory.
>
> I think that you want a "theory for change management with fatally
> flawed tools".

No I want to see a properly extended theoretical relational model of both the data and the programs (because they are inextricably linked and optimally need to be managed, coordinated and changemanaged  together).

>>The RM is powerful but restricted.
>>It does not answer all questions emergent
>>in the modern database systems environment
>
> You are confusing again the RM with the current fatally flawed
> implementations.

The only confusion that exists as a result of my posting appears to be with certain parties who are unable to rationally discuss the evolution of theory of the RM of data (as it was 30 years ago) into a far more powerful theory that addresses a greater spectrum of contemporary database systems issues.

-- 
Pete Brown
IT Managers & Engineers
Falls Creek
Australia
www.mountainman.com.au/software