 | |
Re: Need help to understand difference, and contrast between Relational database model and the Object-Oriented model
comp.databases.object comp.databases.object
 |
| | Thread Tools | Display Modes |
#21
 
| |||
| |||
|
Re: Need help to understand difference, and contrast between Relational database model and the Object-Oriented model -
12-12-2003
, 12:24 PM
|
Due to the flaws of the SQL DBMS implementation. BTW SQL DBMSes can't be considered as truly RDBMSes. Did we lose anything by moving to an ODBMS, you bet we did. We lost out ability to run ad-hoc queries against the data. And you would have a lot to win with a good RDBMS which allows wide physical independence. You would have the same performance or better, ad-hoc queries and the rest of the advantages of The Relational Model. That is what I am trying to say all the time. |
RDBMS"?
--
Bob Nemec
Northwater Objects
#22
| |||
| |||
|
|
You are missing the point. When I said "some sort of physical pointer" I didn't mean direct file offset:... The point of my posting was the static versus dynamic relationships between objects. |
Quote:
|
Relational databases use keys. Object databases use some sort of pointer to physical storage location. |
that it use "static", pointer-driven relationships between objects?
Whose definition of object database are you using that requires this?
Whilst it is common for many OODBMS API's to be highly navigational, the
early material I read by Loomis and Cattell certainly didn't say this
had to be a form of pointer. Jordan's "C++ Object Databases" talks about
associative access and that OODBMS implementations have generally
focussed on static relationships but not that it is necessary or that
ALL have done so.
FWIW OOFILE was designed based on my mixing the early ODMG and other
publications with a strong dose of "what do application developers
really need". Relationships are defined as being based on join keys (as
most SQL environments now allow you to specify foreign key constraints)
OR pointer-based, on a per-relationship basis.
People have been pretty happy with the flexibility this choice provides,
especially when using a legacy database schema which is round-tripped
with a VB/Jet app (as needed in one of the early major OOFILE-based
apps).
Maybe it would clarify the discussion to separate out modelling from
runtime behaviour.
OO modelling tends to focus on static relationships between classes. The
*instances* related may be dynamic (this is one area where I think
people get hung up on the idea of pointers).
In theory, relational modelling allows for dynamic relationships. In
practice, between the amount of code that anticipates relationships in
the data model and the data model integrity constraints, there's enough
inertia that I believe many if not most relational systems are as static
as typical OO models.
--
Andy Dent BSc MACS AACM
OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows
PP2MFC - PowerPlant->MFC portability
http://www.oofile.com.au/
#23
| |||
| |||
|
|
mvk37 (AT) hotmail (DOT) com (Michael Kuznetsov) wrote in message news:<a118d09d.0401012122.68f2e9f7 (AT) posting (DOT) google.com>... Relax pal. So many emotions from a so short message. I have been working both with object oriented design and database design 10 years. It does not mean anything. Sorry if my point of view on this subject is very different for yours. It is not a point of view issue, your post revealed profound ignorance on the topic indeed. |
Show us what you know.
--
Bob Nemec
Northwater Objects
#24
| |||
| |||
|
|
In article <gSzIb.703884$Tr4.1770994@attbi_s03>, Nobody <nobody (AT) nowhere (DOT) net> wrote: You are missing the point. When I said "some sort of physical pointer" I didn't mean direct file offset:... The point of my posting was the static versus dynamic relationships between objects. somebody wrote Relational databases use keys. Object databases use some sort of pointer to physical storage location. Is it really an essential part of the definition of an object database that it use "static", pointer-driven relationships between objects? Whose definition of object database are you using that requires this? Whilst it is common for many OODBMS API's to be highly navigational, the early material I read by Loomis and Cattell certainly didn't say this had to be a form of pointer. Jordan's "C++ Object Databases" talks about associative access and that OODBMS implementations have generally focussed on static relationships but not that it is necessary or that ALL have done so. FWIW OOFILE was designed based on my mixing the early ODMG and other publications with a strong dose of "what do application developers really need". Relationships are defined as being based on join keys (as most SQL environments now allow you to specify foreign key constraints) OR pointer-based, on a per-relationship basis. People have been pretty happy with the flexibility this choice provides, especially when using a legacy database schema which is round-tripped with a VB/Jet app (as needed in one of the early major OOFILE-based apps). Maybe it would clarify the discussion to separate out modelling from runtime behaviour. OO modelling tends to focus on static relationships between classes. The *instances* related may be dynamic (this is one area where I think people get hung up on the idea of pointers). In theory, relational modelling allows for dynamic relationships. In practice, between the amount of code that anticipates relationships in the data model and the data model integrity constraints, there's enough inertia that I believe many if not most relational systems are as static as typical OO models. |
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.