Re: How proprietary is the "COBOL file system"
- From: Robert <no@xxxxxx>
- Date: Tue, 02 Oct 2007 00:19:01 -0500
On Tue, 2 Oct 2007 15:41:21 +1300, "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
.. this is
the great irony .. RDBMS is oriented toward declaratives and thus data,
whereas ODBMS is
oriented toward behavior and thus procedure.
I think the jury is still out on ODBMS...
I think ODBMS is just a file system for objects. I once wrote an OS that simply made all
objects persistent. Its address space was the disk; there was no temporary 'memory'. You
construct an object today, it's still there tomorrow. How simple is that?
I find that well designed RDBMS
support OO processing without problem.
Critics say that's a BIG problem, because it is no longer relational. They say relational
is a two-dimensional world. Replacing atomic data with objects adds at least one dimension
-- the internal structure of the object. Given that components can also be objects, the
table becomes n-dimensional.
There is an inherent conflict between the relational way of finding things via association
and data values (ad hoc heaps and caches) versus the OO way of finding things via
navigational pointers.
There is a conflict between hiding data in objects versus exposing it in an RDBMS.
A solved these in the OS by saying there are two kinds of classes: relational and atomic.
For simplicity, let's say there is only one relational class: collection. An RDBMS row is
a collection of columns, a table is a collection of rows, a schema is a collection of
tables. One could duplicate the functionality of an RDBMS with a well-designed collection
class and a few simple ones for number, string, integer, float, date, etc. Then the object
base would be open to the addition of new atomic classes without destroying its relational
flavor. The caveat is that compound classes, let's call them molecules, are not allowed to
bind their atoms using their own devices, they have to do it through the collection class.
That empowers outsiders to find any data based on association and value rather than the
class' private pointers.
If two dimensions is the holy grail, think of three dimensions as recursive use of two.
Foreign keys add a third dimension, yet no one objects to that. Stored procedures and
views also add a third dimension. Multiple schemas, instances, links to other databases
and URLs make every database n-dimensional.
I know a lot has been said in various
papers about object persistence and optimized object storage, but, for me at
least, it hasn't been a problem (maybe I need to get out more... :-) Next
year...)
When they talk about performance, that's the giveaway we're back to the Good Old Days.
They're designing for the machine's convenience. It's too late; we've gone beyond that for
all but huge databases.
I don't know if you've had a look at LINQ, Query Expressions, and Lamdas,
Robert. I think this is where it's going... C# already supports query
expressions and these support parallel processing, deferred execution,
Lambdas (basically, representing an entire Query with a single symbol that
can be passed around), and media independence. (new molecular storage
technologies, for example, can be accessed in this way...)
LINQ is Microsoft's new improved SQL, in the same way C# is their new improved Java.
Whether you love or hate Microsoft is a religious question.
Query expressions are a new name for multithreading. Databases have been doing parallel
subqueries and parallel partition searches for at least a decade.
Lamdas are math theory, not a developed programming tool. I don't see the difference
between passing a Lamda and passing a function pointer, the name of a method or the handle
of a collection.
.
- Follow-Ups:
- Re: How proprietary is the "COBOL file system"
- From: Pete Dashwood
- Re: How proprietary is the "COBOL file system"
- From: Pete Dashwood
- Re: How proprietary is the "COBOL file system"
- References:
- Re: How proprietary is the "COBOL file system"
- From: tlmfru
- Re: How proprietary is the "COBOL file system"
- From: Robert
- Re: How proprietary is the "COBOL file system"
- From: Pete Dashwood
- Re: How proprietary is the "COBOL file system"
- Prev by Date: Re: Iraq
- Next by Date: Re: rounding
- Previous by thread: Re: How proprietary is the "COBOL file system"
- Next by thread: Re: How proprietary is the "COBOL file system"
- Index(es):
Relevant Pages
|