Re: An object-oriented network DBMS from relational DBMS point of view

JXStern wrote:

> On 9 Mar 2007 03:44:37 -0800, "Dmitry Shuklin" <shuklin_at_bk.ru> wrote:
> 

As others have pointed out in the past, equating a tuple with an object instance is a great blunder. One starts with an n-ary structure and arbitrarily decides to make it a unary structure.

  All table's rows will be instances of a
>>class, which are corresponding to the table. Classes will be defined
>>by table headings. In this case table column will conform to the field
>>of the class. The value of the row field will conform to the value of
>>the instance field. This first iteration of the ODBMS development
>>allows us to work with DBMS in terms of classes, instances and values
>>of instance fields. This OO system is still missing methods, virtual
>>methods overriding, inheritance and encapsulation. Neverless, it is
>>obvious, that no RDBMS values at that ORDBMS interpretation were lost.

However, almost all of the RDBMS manipulation function was lost. That is far too dear a price to pay.

[snip]

>>Object - relational DBMS
>>
>>Lets move further. By analogy with OOP it is possible to implement
>>single inheritance. The table, which has inherited base table, also
>>inherits columns of that base table or, what is equivalently, inherits
>>class fields. Base table should contain all class instances (= rows)
>>from all derived tables, which were inherited from this base table.
>>Some methods can be associated to the row (= instance).

But why on earth would anyone be so stupid as to cripple an n-ary structure down to a unary structure? Especially when one can have operations on both the n-ary structure and the unary elements it contains?

  An interface
>>of the class, which was determined in the basic table, is inherited by
>>derived tables. Each row method should implicitly receive one row as
>>hidden parameter (= this).

What exactly does this hidden parameter mean for a set level operation? Or is someone suggesting anything so stupid as requiring record at a time operations only?

  These row methods can be regarded as class
>>(= table) methods. These methods will be executed on data stored in
>>the row of table (= class instance or this).

Stored in the row of the table? One stores data in physical structures. Logical structures represent data not store it.

  Identifiers of all
>>virtual methods of single class can be stored in some table known as
>>vtbl. Lets add hidden field (= column) with identifier of vtbl to each
>>data table. The vtbl identifier stored in hidden field in each row
>>allows to implementing overriding of virtual methods. The call of
>>virtual method of some row will be implemented as searching of the
>>virtual methods table by the vtbl identifier stored in this row and
>>then searching and calling the implementation of the method by its
>>name in the virtual methods table. The availability of vtbl allows to
>>invocate overridden methods, defined in the derived tables by rows
>>contained in the base table. So, in the developed abstract DBMS
>>support of inheritance and polymorphism concepts are presented.

But why on earth would anyone need to add an implicit and hidden pointer to tuples for this purpose. By complicating the logical structure, one can piss view updatability out the window. What is the vtbl of a natural join?

  Also
>>it is obvious that the addition of such capacity uphold all present
>>RDBMS capacities.

Actually, it is obvious that the addition of this arbitrary physical structure breaks almost all RDBMS capacities like the capacity to uphold the information principle, the capacity for physical and logical independence, the capacity for set-level operation etc.

[snip]

>>The encapsulation is implemented in the developed DBMS by VIEWs using.
>>VIEW allows protect some table fields from direct access, providing
>>the access to fields interface. Due to the availability of vtbl
>>identifier in each row the VIEW also provides access to methods
>>interface.

Views already obviate the need for encapsulation of relations at the logical level of discourse. Adding vtbl doesn't change that, and in fact, breaks it. Physical data independence obviates the need for encapsulation of relations at the physical level of discourse. What has been proposed above does not in any way address the need for abstract data types or for hiding their internal design.

>>As is easy to see, such implementation of OOP concepts in the RDBMS is
>>not new. PostgreeSQL is an example of already existing implementation.

Sadly, I agree. Such ignorant nonsense is altogether too common these days.

[snip]

>>Let's go on. Each row of the table is physically located in the
>>storage at some unique address.

Is it? I suppose if one wants to piss away physical independence one could arbitrarily forbid column stores as well as all partitioning and clustering of data. But why on earth would anyone want to do that?

  Even if it was not yet implemented in
>>the RDBMS used as prototype, it is technically possible to provide
>>invariability of this address during all row lifetime.

Who would be so stupid as to pin data to a single physical location? Are we to assume the exact same data values should mean something different in a spreadsheet than on sector 4238 of a given hard drive?

  The analogue of
>>this address can be bookmarks, used in the modern RDBMS for rows
>>addressing. The availability of unique and invariant row logical
>>address allows us to implement the concept of pointers to the rows.

Candidate keys already give us unique and invariant "logical addresses". Who would be stupid enough to want to replace those with physical pointers? For what purpose?

>>Previously it was developed concepts of inheritance, polymorphism and
>>encapsulation. They are converting developed abstract ODDBMS to
>>valuable OO programming system.

Valuable in what sense? Suggesting that OO can compensate for the loss of physical independence, logical independence, logical identity, set-level operation, set algebra and predicate calculus, n-ary structures and structural simplicity strikes me as absurd nonsense.

If we cut the wings and half the fuselage off a plane and yoke a donkey in front of it, we could similarly talk about the valuable transportation system we created.

>>Note, that the concept of references to the rows is also not new and
>>was embodied long ago in such famous RDBMS, as Oracle.

Sadly, I agree. See my comments above regarding the prevalence of ignorant nonsense.

>>Neverless, it is obvious, that no RDBMS values at that ORDBMS
>>interpretation were lost too. As before, developed abstract ORDBMS
>>includes RDBMS as special case.

Actually, it is obvious that everything but the values was lost, however.

[snip]

>>Network OODBMS

> 
> (skipped)
> 
> 

Horseshit!

[snip] Received on Sun Mar 11 2007 - 13:49:04 CET