Re: S.O.D.A. database Query API - call for comments
Date: Sat, 21 Jul 2001 18:00:43 GMT
Message-ID: <lL2I6.7792$SZ5.640691_at_www.newsranger.com>
In article <9cq8et$thj$06$1_at_news.t-online.com>, Carl Rosenberger says...
>
>Mikito Harakiri wrote:
>> >> >queries step-by-step with many small functions.
>> >>
>> >> Of course, it was exactly to get away from that, that SQL was
>> >> invented.
>> >
>> >I am afraid that object-orientation was not used in those days.
>>
>> Robert Martin on comp.object admitted that OODBMS is no more than
>> persistent storage of nested structures.
>
>No, that is not true.
>Object databases also use indices to organize data for efficient querying.
A checkpoint. If I, say, have a Shape object with overlap() method, what index would OODBMS build?
>Anyway:
>If I were to neglect triggers, stored procedures, constraints and other
>vendor-incompatible constructs that violate object business logic, I could
>respond:
>Relational databases are no more than the persistent storage of flat tables.
Not constraints, please. They are as important for relationists, as encapsulation for objectivist. This is something that distinguishes database out of xml fade, for example (although, there is a paper on constraints in xml in ASM SIGMOD already:-)
>Why do VARCHARs need a fixed length?
It's a shame that in 21st century SQL still has anything like that. It's a mere syntax, however.
>Why do you have to convert objects to strings manually to communicate with
>the database? Can't the database do the job for you? What is the string
>back-and-forth conversion good for?
I'm not following here.
>Why do you need to fetch IDs after inserting records, just to join them to
>other records? Can't the database do the job for you?
You mean:
1. insert master PO record 2. get generated sequence ID back 3. insert items
?
Optimising away #2 here is minor issue, compared to possibility of combining steps #1 and #3. But can't do in Relational. Note, that alhough OO seems to store PO in one shot you previously have constracted PO object in memory in exactly the same steps. So, I wouldn't upset too much here.
>
>> begin quote >>>>>>
>>
>> Object Oriented databases have an unfortunate name. They aren't
>> object oriented at all. Rather they are like large virtual memory
>> areas. The "objects" in an OODB are really just data structures.
>> Their behavior is typically not stored with them.
>
>Behaviour is implicitly stored with objects, due to their binding to a class
>in the programming language. There are approaches that allow method
>interaction on the database side.
Understand first sentence. Robert Martin mentioned that in programming practice those methods tend to float outside of the database.
In second sentence do you mean that you can use methods like Shape.overlap() in queries?
>> Both kinds of database expose data, whereas true OO hides data and
>> exposes behavior. RDBs have little or no behavior.
>
>Where is the advantage of relational databases?
I kind of understand a position of a person from object world. Being able to store/retrieve a network of objects into a stream with a single command and requiring no application programming at all -- pretty impressive for a newcomer.
After all, if we put all relational features into object database, wouldn't it just be a better database? No, not everything scales easily.
>> OODBs sometimes
>> pretend to have behavior (methods in the objects) but developers will
>> find that as the application domain grows they will feel a pressure to
>> move that behavior out of the database classes and into specific
>> application classes.
>>
>> <<<< end quote
>
>I can't see an argument against object databases, if they provide no less
>functionality than relational databases.
It's not necessarily about functionality only. We can retrieve data in both approaches -- no question about it. It is that some object features, like nesting, make quering much more complicated, and relationists think that this is fatal.
>> If nesting is the only feature that you leverage, then the approach is
>> essentially CODASYL, or even worse, hierarhical db.
>
>As to hierarchical databases:
>Are you informed about Ericssons record-breaking approach?
Sorry, I'm ignorant here. You sound alarmingly marketing, though:-)
BTW, I symphasize your early attempts to scare away spammers from the newsgroup. Received on Sat Jul 21 2001 - 20:00:43 CEST