Re: How proprietary is the "COBOL file system"
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 2 Oct 2007 21:52:37 +1300
"Robert" <no@xxxxxx> wrote in message
news:bkg3g3pl2rhs3n58t3ahp95677lhdtshe6@xxxxxxxxxx
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.
That's only problematic if you care about strict compliance with theory.
Most of us have spent our careers making things work. For me, standards and
theory are fine, but I'll bend them if it helps me get what I want. If
someone criticised what I did as violating Relational theory, I'd say: "Yes,
from a CS point of view, it's pretty crap really... Have you talked to the
Users?" The point is that it doesn't matter what theoretical objections
people have, as long as the results are obtained. Having said that, I don't
deliberately break the rules unless there is a sound reason for doing so.
(I'm also not "precious" about what I design or write...)
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.
I have not considered it in that way, but I don't disagree.
There is a conflict between hiding data in objects versus exposing it in
an RDBMS.
Sometimes... :-) Depends on the lifetime of the data...
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.
An interesting approach...
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.
I don't see it quite as black and white as that :-) I neither love nor hate
MicroSoft, or any other software company. I appreciate that they make
powerful products available for free, whether out of sound business sense or
otherwise. I like C#; it delivers what it promised, I like VS 2005, it is
light years ahead of other IDEs (possibly excepting Eclipse, which is also
excellent), I'm very happy with MS Office, use it every day and it serves me
well, I have grown very attached to Windows XP and IE7, but I'm in no hurry
to move to Vista (I believe it will be much better after SP1...meantime, XP
is behaving very well - I have never had a crash or hang or BSOD on
Bigblack which has been running now for almost a year (I think a more
powerful processor and 2GB of main memory may be the reason, but I don't
care... I just enjoy it :-), and my most favourite thing about MS would be
the DotNET framework:-)
I'm not happy about the exorbitant cost of Vista Ultimate 64 bit, which is
what I'll go to when I move. By the time I get to it the price will probably
be a bit lower.
It is all swings and roundabouts. I am generating revenue with something
they gave me for free, so of course that predisposes me in their favour.
I've also found them to be helpful and courteous when I have needed support
(two occasions in 7 years and one was really a Fujitsu problem.) The user
community is also very helpful.
Query expressions are a new name for multithreading. Databases have been
doing parallel
subqueries and parallel partition searches for at least a decade.
Yes, but you had to encourage them to do so, and deferred processing was not
an option. Now you can have a series of processes react to a given Lambda
without any actual data transfer taking place. (It is Functional
Programming...) Steps in the process can modify the Lambda and only at the
end is data actually accessed, and then it is only what is needed for the
final result. It is pretty smart.
I don't know if it is still available, but there was a really excellent
video of Anders Hejlsberg (who invented C#) talking about this.
Ah, here it is:
http://blogs.msdn.com/charlie/archive/2007/01/26/anders-hejlsberg-on-linq-and-functional-programming.aspx
I think you'll really enjoy this. I found it like a breath of cool oxygen...
it cleared my head :-) The "ORCAS" he refers to is C# version 3 which is now
released and downloadable from:
http://www.microsoft.com/downloads/details.aspx?familyid=281FCB3D-5E79-4126-B4C0-8DB6332DE26E&displaylang=en
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.
I agree the similarity, but combining this with Query Expression goes a
quantum leap beyond current SQL. (I believe that embedded SQL is already
obsolete; and I'm gradually weaning myself away from it :-)) Integrating
Query Expressions as classes in the Language is, in my opinion, a much
better approach. Functional Programming rules!
Pete.
--
"I used to write COBOL...now I can do anything."
.
- Follow-Ups:
- Re: How proprietary is the "COBOL file system"
- From: Robert
- 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"
- From: Robert
- Re: How proprietary is the "COBOL file system"
- Prev by Date: Re: rounding
- Next by Date: Re: How proprietary is the "COBOL file system"
- 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
|
