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

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? As an analogy, were, say, electric cars a bad idea, a good idea done poorly, or subsumed entirely by hybrids? (Let's not get too caught up in the analogy, though--I'd like this sub-thread to be about your thoughts on OODBMS vs. RDBMS vs. ORDBMS, not about electric cars ;-)

Regards,

--Jeff Received on Fri Apr 20 2007 - 20:07:02 CEST