Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: relational vs object

Re: relational vs object

From: Patton HalfTrack <halftrack_at_asylum.for.retired.generals.org>
Date: Fri, 01 Mar 2002 22:31:28 GMT
Message-ID: <4kvv7ug8v02mujt637ar23ugi02n4211mr@4ax.com>


Carl:

    This is not a "flame". But .... What about the situation where they take us to the store. And, I have my 10 items. I am in the Express CheckOut line. She scans my items through and ... this happens 50 % of the time !! No Beep.

    "Price check on Counter ... " whatever.

     I got 3 ex- green berets, another general, and somebody who thinks he served with Admiral Phung Tu in the First Polyponesian War - standing behind me, angry, and these guys do NOT care about the difference between the theory of relational and object oriented databases.

    I try to explain to them, while we are WAITING - about the structure of classes, why my item did not register in the database, and then the Phung Tu guy goes abso-completely-nuts and we have to tackle him to the ground and Elliott the van driver has to grab the tip of his tongue so he doesn't swallow it.

    What kind of a database system is this ? With no beep. You have a NO Beep kind of a database here is what you have !! No Beep. What is SO complicated about making EVERYTHING in the store F*CKING Beep !! (Sorry about the asterisk)

On Fri, 15 Feb 2002 01:36:52 +0100, "Carl Rosenberger" <carl_at_db4o.com> wrote:

>Angus Monro wrote:
>> What are the pros & cons between relational & object databases?
>
>
>Angus,
>
>to get the discussion going, I will supply the cons that I just
>recently posted to comp.databases.object.
>
>Since we are working hard on our 2.0 release, I am sorry not to
>have the time for a flame war, that is likely to develop but I
>will enjoy reading along the "Not true" and "but its ad hocery
>and against relational theory" replies that some of the candidates
>here like Lee or Bob may deliver.
>
>Here we go:
>
>(1) Object databases understand objects. You do not need an exchange
>layer to convert objects to tables. This greatly reduces the implementation
>work necessary to build the persistence code in your application. Some
>research figures talk about 20% to 50% less work during application
>development. Create your classes and store instances of the objects, thats
>all you need to do. You do not have to write SQL-Code to interface with the
>database. The reduced implemetation work also reduces the search for errors
>and improves the maintainability of your code. There is no risk of forgetting
>unsafe SQL-strings in your application during refactoring.
>
>(2) Object databases support class inheritance.
>Relational databases support this concept very badly:
>Either you work with one table for the entire class hierarchy or you
>use one table for every class. The first approach produces monster
>tables. The second approach needs lots of links during storage and
>retrieval and makes queries very slow.
>
>(3) Object databases allow you to navigate through your stored object graph.
>You can follow links of objects without the need to start further queries.
>The object database ensures that the graph of your objects is put together
>in exactly the same way as it was stored. It manages object identities by
>using object caches and ensures that one unique object will only be
>instantiated once. With this concept memory usage can be drastically lower
>in comparison to a relational application where you are served the same
>data over and over again.
>
>(4) Object databases are faster for many tasks. Ideally the database engine
>can be run in-process with your application, without the need for a communication
>layer.
>
>(5) Object databases do not limit you to fixed length strings or arrays. They
>manage your objects as they come.
>
>(6) Object databases come with built-in ID-management. You do not have to
>worry about creating and fetching primary keys or foreign keys. Objects
>are automatically associated with IDs.
>
>(7) Since objects have unique IDs, object databases can do a lot of the
>caching work on the client side. This can greatly reduce the load on your
>server and improve the speed of your application.
>
>(8) Object databases may understand the structure of your classes directly,
>by analysing your code. Ideally you have zero maintenance work to manage
>a "database scheme" (class scheme for object databases).
>
>(9) Object databases may use callback methods to notify your code about certain
>database events.
>
>(10) If the object database is written in the same programming language as your
>application code, it may be possible to compile the complete application to
>native code, including the database engine. This may get you the most efficient
>and small compound application, ideal for embedded use or for use in low
>ressource environments like mobile phones.
>
>(11) If your application interfaces an object database your application code
>can be completely written in one programming language. The programmers do not
>have to learn an additional databases language like SQL.
>
>
>Kind regards,
>Carl
>---
>Carl Rosenberger
>db4o - database for objects - http://www.db4o.com
>
>
Received on Fri Mar 01 2002 - 16:31:28 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US