Quite a while ago, I heard about Object databases. Cool concept and all. Now, with the event of ORMs everywhere, does anyone still use any of the Object oriented Databases systems? Are they relevant? Are they practical?
Are Object oriented databases still in use?
Asked Answered
OO databases never got out of a niche market. They are good for some applications - where the data structure lends itself to being represented by an object graph - but never held the compelling advantage over a RDBMS to cross the chasm. The key advantage touted for OODBMS products is the tight integration to the host language - there is no object/relational impedance mismatch.
However, there are still several OODBMS vendors such as Gemstone, Versant or Cardinal who are doing quite nicely with their products. The technology is useful for some types of data structures and can be more efficient than a RDBMS but tends to be weak for ad-hoc queries compared to modern SQL dialects.
As various others have noted, Gemstone is getting a bit of attention due to their support for Seaside and Maglev (a port of Ruby to the Gemstone VM with Rails running on it). We may find this gets the nice folks from Gemstone a bit of press and with it a bit more attention to the OODBMS paradigm.
Querying in a OODBMS such as Gemstone is much stronger for ad-hoc queries than SQL. –
Symphysis
In fact, database systems are one of the areas that fundamental changes are really hard. Billions of dollars are spent on relational database systems and they are working pretty well.
In real life, that's simply not true. A major reason for our problems with databases (I saw a claim 30% of all database rows contain errors) is the use of very primitive typing and validating in SQL. In addition, even though they are named relational, they are very bad at handling relations . The result is denormalized datamodels and resulting update errors.
The reason businesses like relational databases is because they are very predictable. They have to spend a lot of money on them, they need a lot of developers and maintenance doing mostly routine jobs. They fail to see the amount of duplication that could be eliminated as an advantage. The routine work allows developers to absorb the risks of the difficult work. Switching to an OODB would keep the less predictable work.
In fact, database systems are one of the areas that fundamental changes are really hard. Billions of dollars are spent on relational database systems and they are working pretty well. They are proven technology and they have been flexible enough to satisfy most needs (using ORM for example, as you said). Object databases do exist actually, even outside academia. But don't expect to see anything as big as SQL Server or Oracle in that area anytime soon. They do exist as a theory and as small, application-specific databases and various products. Basically, I predict relational databases become more object oriented in the future to handle requirements better.
I started using Gemstone recently. GLASS (Gemstone on Linux (or OS-X) with Seaside (smalltalk web framework)) is probably the best web development environment for complex applications. Smalltalk is making a revival, being "the real ruby".
The support for schema changes and querying is far superior to that in RDBMS.
An important difference is that this time they are affordable.
We use Versant Object Database in the product I work on. (Formerly FastObjects, formerly Poet database). It's an object database and we find that it works much better than a relational model for some aspects of our product, primarily storing configuration objects, interfacing with Java code.
See also this previously asked question: https://stackoverflow.com/questions/52144/object-oriented-database-experiences
I needsome help on fast objects . I often run out of Virtual Memory when I parse an XML of around 15 GB . I am using an expat parser . Do you have a similar experience ? –
Palaeography
We don't really do any parsing of XML ourselves, we use the 'ptxml' utility from Versant to do export/import of FastObjects databases in XML format, but that's about it. –
Langsyne
Because the cost of their software isn't easy enough to find out.
I checked out Objectivity, db4o, versant, and none of them have the price of software up front on their website.
I've already almost lost interest just because of that.
Does anyone know anywhere where there is a pricing and license comparison of all these different oodbs?
+1 for that. "Call us for a quote" always means "ridiculously expensive" - there simply seems to be no good, affordable or non-viral OSS, mature Object Database. –
Valvule
objectivity has come a long way since this post, it is still quite expensive, however –
Mingle
Using GemStone for a large business application. It's great and It's very practical. We've used it for several years and over that time it has enabled us to do a lot with very little resources. Unfortunately there are and have been numerous misconceptions about object databases and I think this makes them less relevant in the business world. Hopefully something like GLASS (GemStone, Linux, and Seaside Smalltalk) will change that going into the future.
Object Database is a cool concept up to now. However, implementations are plaqued with Scalability and Stability issues. Now with the right incarnate that addresses these two beasts, the equation may change.
What I thought is, a Data Engine (not necessarily Object Database) and RDBMS can really live side by side, in fact, there is a great place for a Data Engine in the Middle-Tier, Embedded Apps/systems,... Also, a correct implementation of a Data Engine will allow support for both Object Persistence at a low-level and at higher level, RDBMS/SQL constructs. This means your application can choose to work with Objects, use the data engine for Object Persistence AND make the Objects available as Rows/Columns of a table via an RDBMS interface.
This is the ideal setup. We bridge the two technologies and provide alternatives for developers to program in their preferred interface. One may argue we have this now, e.g. - SQL Server has support for hosting CLR Objects, BUT the current implementations suffer from impedance slowdown. i.e. - in the data path is a lot of conversions/translations as Objects != two dimensional data, thus when your App which deals with Objects saves them to DB, the solution has to convert/translate them to row data in a table.
BUT if we reverse the situation, i.e. - the data engine operates on Objects then there will be no impedance mismatch. Adding two dimensional data projections is nothing more than interface implementation of an Objecct Collection, thus there isn't really no mapping/translation that occur when Objects are exposed as data rows of a table. This is my theory.
SO it maybe the next wave of technology on this area is a data engine that will allow Objects as low-level interface and RDBMS interface sitting atop of it. AND this technology is available now!
B-Tree Gold version 4.0 Scalable Object Persistence has this as its main design Goal. It achieves the following characteristics and thus, it is well adapted to being the data engine of choice for the next RDBMS, which basically is a layer on top of it. Two of its main key points are: Scalability: 100 million Inserts in 17 hrs in an ordinary/avg equipped laptop. Stability: industrial strength transaction that will ensure DB is not corrupted and can rollback to a previously committed state.
For this to work, the data engine has to meet scalability and stability required by RDBMS Servers. A very tough task but not impossible. B-Tree Gold version 4.0 SOP has met this requirement, thus, we're really ready to implement this kind of solution, without really shoving it under our neck as SOP gives freedom of choice how you'd like to use it. It can be used in a lot of ways, e.g. - complementing RDBMS Servers as middle-tier caching station, embedded DB in the client side, etc... not to mention being the low-level data engine of the RDBMS server itself!
At least from my point of view they are pretty much dead. But then again I'm working primarily in commercial software. Maybe in academic areas they are still in use somewhere.
© 2022 - 2024 — McMap. All rights reserved.