Re: Is it possible to use a database though any high-level API?

From: Volker Hetzer <firstname.lastname_at_ieee.org>
Date: Wed, 02 May 2007 21:06:38 +0200
Message-ID: <f1angl$13c$1_at_nntp.fujitsu-siemens.com>

jefftyzzer schrieb:

> On Apr 12, 9:06 am, "Aloha Kakuikanu" <aloha.kakuik..._at_yahoo.com>
> wrote:

>> On Apr 12, 5:44 am, beachmount..._at_hotmail.com wrote:
>>
>>
>>
>>
>>
>>> Hi!
>>> I hope I am posting this in the correct group, I am quite new to
>>> usenet posting.
>>> I have only been working in the computer area for a couple of years,
>>> and my experience with databases is limited to a five week course
>>> during my education.
>>> As I think about an application I want to develop, I have a question
>>> about databases that I would love to have someone shine a light on.
>>> The question is, is there any programming tool available so that I do
>>> not need to contruct a database "by hand", that is, I would like to
>>> have an API to use so that I can easily store the implemented objects
>>> in my object-oriented solution without caring about how they are
>>> stored?
>>> It seems to me that it would be a perfect task for a computer to
>>> translate my objects into relational tables or some object-oriented
>>> representation. It seems redundant that I should have to create TWO
>>> models, one in the object-oriented implementation, and one for the
>>> database (for instance creating tables with columns and so on), when
>>> the two models are just different representations of the same objects
>>> and relations between objects (or am I totally wrong here?)
>> The answer is really depend whom you ask. Object Oriented
>> propellerheads would point you to the object relational mappers, which
>> are essentially crippled object oriented databases. Most people on
>> this group, however, would indicate that if the utter failure of
>> object oriented databases taught us any lesson, that would be the idea
>> that objects are not suitable for data management.
>>
>>> If I have two classes, Person and House, and a House can have one
>>> Person as an owner:
>>> Person bob = new Person("Bob")
>>> House castle = new House("Castle")
>> Ask yourself, is the "person" really an object. I see a bunch of
>> fields bundled into a record structure, and fail to see any methods.
>> You can perfectly program your application where your business data is
>> not artificially bundled into objects. In a word, keep objects for GUI
>> stuff, don't use them for data management.- Hide quoted text -
>>
>> - Show quoted text -

> 
> How much (if any) of the "utter failure" of OODBMS's would you
> attribute to their being a bad idea vs. bad execution vs. the market
> dominance and self-preservation (if you will) of the major RDBMS
> players vs. the major players having added just enough object features
> to satisfy object folks' needs?

This is just my personal and entirely unresearched opinion but here is (in decreasing order of importance):
- bad idea. IMHO there's no theory behind them, apart from inheritance

   resolution and such. But this is about internal stuff and not what to    do with objects. Relational theory however is a lot about what to do    with the data and not about internals. And developers care about what    to do with the data. Which, for OOP stuff turned out to be "you can    store and retrieve it". That's entirely different from what real    databases are about, namely "you can calculate with the data" (not its    values but all the set and join things). - bad execution: What about replication, load balancing, hot backups, I/O

   tuning? The relational biggies were light years ahead in that game. Also,    for valuable Data, a track record is important. Look at MySQL to see how    long it takes to build one.
- major players adding a bit of OO camouflage: That (plus the stuff from

   point two) was good enough to convince the managers to let the db guys    work with real databases. Then the db guys quietly dropped the OO stuff    and management and customers only cared about results. - self perservation: this was the reason the OO stuff was added.

Uh, here's another point: The OO databases I had seen only had programming language interfaces like for C++ or Java. No query language, no console or other ad-hoc query tool.

Lots of Greetings!
Volker

-- 
For email replies, please substitute the obvious.

Received on Wed May 02 2007 - 21:06:38 CEST