RDBMS vs ODBMS
GinTon
1- Objects in an OODBMS can store an arbitrary number of atomic types
as well as other objects. The fact that an OODBMS is better suited to
handling complex,interrelated data than an RDBMS means that an OODBMS
can outperform an RDBMS by ten to a thousand times depending on the
complexity of the data being handled.
2- Data in the real world is usually has hierarchical characteristics.
The ever popular Employee example used in most RDBMS texts is easier to
describe in an OODBMS than in an RDBMS.
3- A query language is not necessary for accessing data from an OODBMS
unlike an RDBMS since interaction with the database is done by
transparently accessing objects. It is still possible to use queries in
an OODBMS however.
4- In a typical application that uses an object oriented programming
language and an RDBMS, a signifcant amount of time is usually spent
mapping tables to objects and back. This "impedance mismatch" is
completely avoided when using an OODBMS.
5- The user of an RDBMS has to worry about uniquely identifying tuples
by their values and making sure that no two tuples have the same
primary key values to avoid error conditions.
6- With an RDBMS it is not possible to model the dynamic operations or
rules that change the state of the data in the system because this is
beyond the scope of the database. With an OODBMS there is no disconnect
between the database model and the application model because the
entities are just other objects in the system.
http://www.kuro5hin.org/?op=displaystory;sid=2001/5/3/32853/11281
http://www.odbms.org/introduction_whenODBMS.html
http://en.wikipedia.org/wiki/Object_database
Ian Holsman
what exactly are you proposing here?
with a OODBMS you shouldn't need any of the ORM functionality.. you
should be able to just use the other sections without
much worry i would suspect.
regards
Ian
--
Ian Holsman
I...@Holsman.net
GinTon
> yes..
> what exactly are you proposing here?
>
> with a OODBMS you shouldn't need any of the ORM functionality.. you
> should be able to just use the other sections without
> much worry i would suspect.
>
web frameworks with ODBMS will be the next big step.
The problem is that today it is not a true option since that it only
exists a free ODBMS based on the ODMG 3.0 specification, ozone, that
has been built in java.
http://en.wikipedia.org/wiki/Object_database
http://www.ozone-db.org/frames/home/what.html
As it is said in 4 point, It's true that using a ODBMS would not be
necessary the ORM functionality, another more advantage.
Karl Guertin
> I wanted to know your opinions. Since of my view point I think that the
> web frameworks with ODBMS will be the next big step.
I prefer an RDBMS because I tend to integrate with other
projects/languages at the RDBMS level. The other advantage is that the
RDBMS are much better tested because they're in wider use.
I can usually handle the impedance mismatch, even though ORM is the
Vietnam of Computer Science[1].
[1] http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
Mir Nazim
> projects/languages at the RDBMS level. The other advantage is that the
> RDBMS are much better tested because they're in wider use.
I second carls opinion. With RDBMS you easily create a gui app that
connects to the db used by some web apps. and best thing GUI is
completly independent of web app. I mean I can have my web app in
python and my gui in c++ or vice versa. More over OODBMS's are way too
language specific due to the differences in object models in various
languages.
But if you know of an OODBMS that understands the object model of
python, java, .net, c++, ruby, perl, php etc. and translates between
them transparently, I will use that.
Alan Green
>
> On 8/30/06, GinTon <jon...@softhome.net> wrote:
> > I wanted to know your opinions. Since of my view point I think that the
> > web frameworks with ODBMS will be the next big step.
>
> I prefer an RDBMS because I tend to integrate with other
> projects/languages at the RDBMS level. The other advantage is that the
> RDBMS are much better tested because they're in wider use.
Leaving aside technical considerations, OODBMS's are simply
unacceptable to many organisations. My company's clients are even wary
of what they would call "new and untested" RDBMSs, such as MySQL and
PostgreSQL!
Alan.
--
Alan Green
al...@bright-green.com - http://bright-green.com
Bjørn Stabell
> I have seen that for web applications is best far using a ODBMS:
>
> 1- Objects in an OODBMS can store an arbitrary number of atomic types
> as well as other objects. The fact that an OODBMS is better suited to
> handling complex,interrelated data than an RDBMS means that an OODBMS
> can outperform an RDBMS by ten to a thousand times depending on the
> complexity of the data being handled.
This is a bit off-topic, but I just wanted to share some experiences
that brought me to Django, a choice I'm very happy with so far.
Having spent more than 6 years with Zope and ZODB I'll have to say I'll
never touch an OODBMS ever again. I realize ZODB may be perfectly fine
for some situations, and there are other OODBMS's out there that are
probably better, but it struck me that a lot of what makes databases
cool are not yet solved well in Zope 2 / ZODB. For example:
* optimization tools
* dependable recovery tools
and my favorite examples are inlined in responses below.
> 2- Data in the real world is usually has hierarchical characteristics.
> The ever popular Employee example used in most RDBMS texts is easier to
> describe in an OODBMS than in an RDBMS.
Django models are pretty darn straightforward. Seems like everyone in
our organization, even non-programmers, feel pretty comfortable
creating model files! (Not that we let everyone do it :)
At least with ZODB the concept of a schema is not that strong. You can
pretty much put anything you want into the database. That sounds great
at first, but try debugging a program running on a 3-year-old database
with 5 different versions of the same object, all lacking different
attributes or storing differently typed versions of the same attribute.
True, you can solve this with migrations, but at least with an RDBMS
you can make the assertion that "all data is this way and will stay
this way" very easily, and being to make that assertion is essential to
achieve peace of mind.
> 3- A query language is not necessary for accessing data from an OODBMS
> unlike an RDBMS since interaction with the database is done by
> transparently accessing objects. It is still possible to use queries in
> an OODBMS however.
A QUERY LANGUAGE
You'll always want to search objects and RDBMSs are excellent at
indexing and searching/ querying. ZODB doesn't really deal with this;
you do that at the application level, which just isn't as robust or
efficient, and you'd want something as basic as this robust and
efficient. The best way to do cataloging for an OODBMS is probably to
store all the metadata in an RDBMS, and in this case I have to ask: so
why do you even need the OODBMS?
http://www.faqs.org/docs/ZopeBook/SearchingZCatalog.html
> 4- In a typical application that uses an object oriented programming
> language and an RDBMS, a signifcant amount of time is usually spent
> mapping tables to objects and back. This "impedance mismatch" is
> completely avoided when using an OODBMS.
This is taken care of by the ORM.
> 5- The user of an RDBMS has to worry about uniquely identifying tuples
> by their values and making sure that no two tuples have the same
> primary key values to avoid error conditions.
WELL-DEFINED REFERENCES
RDBMSs are all about references, and ORMs can map those to "pointers".
The identity of an object is well defined and understood. For Zope
programmers at least, storing pointers in ZODB was pretty much black
magic. Again, people would create application-level (products)
solutions for pointers, something that basic should really be rock
solid, well-defined, and implemented in the database itself. Oh the
horrors of past...
> 6- With an RDBMS it is not possible to model the dynamic operations or
> rules that change the state of the data in the system because this is
> beyond the scope of the database. With an OODBMS there is no disconnect
> between the database model and the application model because the
> entities are just other objects in the system.
It is pretty easy to store anything you want in a RDMBS, including
methods, just pickle it. After all, that's what ZODB does.
Sorry for the Zope/ ZODB bashing. I guess I'm really *REALLY* just
hoping Django stays away from mimicing Zope too much; the mixing of
admin interface and model stuff is already too close for my liking
(polluting the schema, IMO).
To end on a good note: Zope's got good full-text indexers. I hope
Django can improve in this respect.
Rgds,
Bjorn
Kevin Teague
Having done a decent amount of work in both an RDBMS and an ODBMS
(mainly PostgreSQL and the ZODB). It has definitely been a love/hate
relationship for me - when I am working in an RDBMS I yearn for a
ODBMS and vice-versa. The grass is always greener ...
Some Pros for an ODBMS:
* Embeddable: Having your database embedded within your application
can be quite useful in certain cases. Here the ZODB is a good
competitor to SQLite (http://www.blueskyonmars.com/2005/06/18/zodb-vs-
pysqlite-with-sqlobject/). Some portion of Plone's popularity has
stemmed from it's ability to ship with a database that is managed as
part of the application, as not having to pick and install an RDBMS
is one less barrier to entry.
* Model Inheritance: Doing model inheritance with pure objects is
very easy. Jeffrey Shell has done some light comparisons of
ActiveRecord versus the ZODB. http://griddlenoise.blogspot.com/
2006/03/yay-object-database.html
* Rapid Prototyping: You've got some data that you've cooked up in
Python, say a tuple of dictionaries. With on object database you can
just store that data as an attribute on your object - sure it's messy
and your code to access the data breaks encapsulation, but sometimes
it's damn nice to be able to just prototype without design tables to
hold every bit of data. Also, I've seen Perl developers abuse the
filesystem and treat it like a database, certainly any DBA would
cringe at such practices, but damn Perl developers can bang out
prototypes and do migrations insanely fast.
Bjorn has pointed out many of the pros of relational database
already, such as easy indexing, SQL is a widely known standard,
referential integrity and strict data type enforcement. A couple
additional points and corrections in defense of an object database:
* You can integrate a GUI with an object database quite easily.
John Barham recently gave a talk about this at the Vancouver Python
Conference (http://www.vanpyz.org/conference/2006/proceedings/8rMJUi/
RestZope.html). Having your GUI talk to your application services via
REST instead of doing SQL from the client GUI is going to allow you
to keep all your business logic in one place, and doesn't tie you to
a specific schema.
* Storing pointers: In Plone this is provided at the framework level
in Archetypes. You can have a ReferenceField which makes it very easy
to refer to another object. Relational databases of course excel at
references, and it does feel nicer to have this functionality be very
robust and lower down in your framework stack.
* Quering: SELECT statements and schemas make it very easy to walk up
to a foreign system and easily understand it and query it. However,
having to maintain indexes at the framework level means that Plone
(and other CMF-based systems) allow you to query multiple content
types with a single API call (something that I've not seen a RDBMS-
backed framework do, although I suspect some of the Java ones might?):
results = context.portal_catalog.searchResults( Type=['Document',
'File', 'Image'], Creator='kteague')
* Schemas: In Plone many people use UML to diagram the schema and
workflows and then simply export that into a Plone product using
ArchGenXML. In Zope 3 there are Schemas and interfaces which are both
quite good at building clean data models.
Finally, in defence of RDBMSes it is possible to "model the dynamic
operations or rules that change the state of the data in the system"
as this is what stored procedures are often used for (for better or
worse).
Anyways, I've enjoyed (and cursed) using both relational and pure
object databases as they each lead the developer to approach the
problem from a different perspective and using both ultimately helps
me to create better data models regardless of which system I happen
to be working in at the time.
- Kevin Teague
GinTon
ODBMS based on the ODMG 3 specification althought it only has
programming interfaces for C++ and Java, but we would ask to authors an
interface for python.
http://www.eyedb.org/
It is very powerful, mature, safe, stable. I was made a vey well
impression with its characteristics:
http://doc.eyedb.org/manual/html/Overview/index.html
It was developed in 1992 for the Genome View project, rewritten in 1994
, and has been used in a lot of bioinformatics projects
http://www.eyedb.org/history.php
If you want to know more about ODMS here you hace some interesting
links:
http://www.dacs.dtic.mil/techs/oodbms2/oodbms-toc.shtml
http://archive.devx.com/dbzone/articles/sf0801/sf0801-1.asp
Ian Holsman
On 08/09/2006, at 8:03 PM, GinTon wrote:
>
> Zopdb is not based on the ODMG 3 specification but I have found a free
> ODBMS based on the ODMG 3 specification althought it only has
> programming interfaces for C++ and Java, but we would ask to
> authors an
> interface for python.
> http://www.eyedb.org/
>
I believe eyedb can do python via SWIG.
it's one of those things I keep meaning to learn when I get some
spare time.
>
--
Ian Holsman
I...@Holsman.net
join http://gypsyjobs.com the marketplace for django developers
GinTon
> On 08/09/2006, at 8:03 PM, GinTon wrote:
>
> >
> > Zopdb is not based on the ODMG 3 specification but I have found a free
> > ODBMS based on the ODMG 3 specification althought it only has
> > programming interfaces for C++ and Java, but we would ask to
> > authors an
> > interface for python.
> > http://www.eyedb.org/
> >
>
> I believe eyedb can do python via SWIG.
> it's one of those things I keep meaning to learn when I get some
> spare time.
>
the implementation of this ODBMS, is there any volunteer?
Anyway I contacted with eyedb.org in order to know its opinion about a
Python interface and the XML support.
rikl...@gmail.com
http://www.riverbankcomputing.co.uk/sip/
PyQT4 bindings made with SIP are realy nice :)
GinTon
SIP generates the fastest wrappers:
* Manual wrapping is still fastest and most versatile
* SIP, Boost and Babel generate native extension modules with low
overhead
* SWIG-generated modules rely on pure Python wrapper module and
introduce a large overhead
* Wrapper tool highlights:
- SIP generates the fastest wrappers
- SWIG is mature and well documented
- Boost.Python most elegant integration of C++ and Python
- Babel supports languages as both target and source
GinTon
> Anyway I contacted with eyedb.org in order to know its opinion about a
> Python interface and the XML support.
"We planned to introduce soon a plugin mechanism to facilitate the way
to write language bindings such as PHP5, Python, PERL and so on. But we
do not know yet if the Python binding will be written by the core
staff.
We do not plan to support XML in the few months. But as eyedb is an
open source project, we expect that somebody else will write supports
for XML."
In any case I advised to him that the creation of a Google group would
be positive to obtain a community interested in that project.