Comment Re:OOP versus Relational (Score 1) 114
The problem with the third is that OODBMS have no real guiding principles.
Yes they do have a very strong and standardized guiding principle: The programming language. A good object database simply let's you program as if all objects were in memory at all times. It is transparent to your application wherever it can be. A good object database does not need a large API with arbitrary semantics. You may want to look into Native Queries for a possibility how even queries can be expressed in terms of your OO programming language.
They are just a mass of virtual pointers: a big graph of maps (dictionaries) essentially with a sprinkling of inharitence.
Why would you want to worry about the physical implementation inside an object database? You don't have to. Do you worry about the physical implementation of Java or C# or just about any program? Just a "mass of pointers", right? If you think about it even a relational database is implemented with a "mass of pointers".
An object database let's you design your application in your OO language in any way you want. You can choose if you want references to point from children objects to parents or if you want to use lists or maps in your objects.
Just write your app in plain OO like you are used to do it and let the object database engine handle persistence for you. No limitations for inheritance, no mapping code, no SQL, no strange code in your app at all that is not checked by the compiler.
Similar DB's ("navigational") are what prompted Dr. Codd to formulate relational to begin with in the late 60's. OODBMS have not solved the original problems of navigational DB's yet.
In the late 60's we did not have object-oriented programming languages yet. At that time there was indeed no guiding principle to build upon.
Today we have many successful OO languages like Java or C#. Object databases are a natural fit and they integrate very nicely and seamlessly. What't the "problem" ? No problem at all that I can see, really.
Yes they do have a very strong and standardized guiding principle: The programming language. A good object database simply let's you program as if all objects were in memory at all times. It is transparent to your application wherever it can be. A good object database does not need a large API with arbitrary semantics. You may want to look into Native Queries for a possibility how even queries can be expressed in terms of your OO programming language.
They are just a mass of virtual pointers: a big graph of maps (dictionaries) essentially with a sprinkling of inharitence.
Why would you want to worry about the physical implementation inside an object database? You don't have to. Do you worry about the physical implementation of Java or C# or just about any program? Just a "mass of pointers", right? If you think about it even a relational database is implemented with a "mass of pointers".
An object database let's you design your application in your OO language in any way you want. You can choose if you want references to point from children objects to parents or if you want to use lists or maps in your objects.
Just write your app in plain OO like you are used to do it and let the object database engine handle persistence for you. No limitations for inheritance, no mapping code, no SQL, no strange code in your app at all that is not checked by the compiler.
Similar DB's ("navigational") are what prompted Dr. Codd to formulate relational to begin with in the late 60's. OODBMS have not solved the original problems of navigational DB's yet.
In the late 60's we did not have object-oriented programming languages yet. At that time there was indeed no guiding principle to build upon.
Today we have many successful OO languages like Java or C#. Object databases are a natural fit and they integrate very nicely and seamlessly. What't the "problem" ? No problem at all that I can see, really.
