Re: Is it possible to use a database though any high-level API?
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Fri, 20 Apr 2007 21:17:30 GMT
Message-ID: <K5aWh.26454$PV3.271190_at_ursa-nb00s0.nbnet.nb.ca>
>>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 -
Date: Fri, 20 Apr 2007 21:17:30 GMT
Message-ID: <K5aWh.26454$PV3.271190_at_ursa-nb00s0.nbnet.nb.ca>
jefftyzzer wrote:
> 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
Jeff,
100% bad idea. Circa 1995 these idiots were warning me about the "tidal wave" that was going to wash non-OO folks away. I predicted ODBMS would fail, and it did. After all, it was nothing more than a re-hash of the network model.
Some of Rick Cattell's earlier stuff was quite good and balanced. I think he wasted a decade where he could have pursued better things. Received on Fri Apr 20 2007 - 23:17:30 CEST