Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase 1234»»»

Why Object Databases will always be Tomorrow's Technology Expand / Collapse
Posted Tuesday, June 16, 2009 10:51 PM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: Administrators
Last Login: Monday, November 28, 2016 10:48 AM
Points: 569, Visits: 1,145
Comments posted to this topic are about the item Why Object Databases will always be Tomorrow's Technology
Post #736207
Posted Wednesday, June 17, 2009 6:03 AM



Group: General Forum Members
Last Login: Today @ 4:52 AM
Points: 17,172, Visits: 32,134
Excellently stated. I wish I had been able to come up with these exact arguments a year ago when one of our major projects started down the object database path. Now... we're expecting their delivery in about a year and no one has a clue how we're going to integrate it with all the other systems. It was developed with the idea that integration wasn't a need for the initial delivery and therefore, no integration points at all. It's going to be the perfect silo, but instead of making it more useful to the enterprise, it will be less useful. Fun times ahead. Thanks for posting such a concise summary of the issues.

"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of:
SQL Server Query Performance Tuning
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #736431
Posted Wednesday, June 17, 2009 6:38 AM



Group: General Forum Members
Last Login: Thursday, February 5, 2015 1:08 AM
Points: 1,893, Visits: 3,934
Nice article!

Another reason for the "tomorrow technology" I heard sometimes:
"Tomorrows hardware will fit the performance lack of object databases"
"Tomorrows data have tomorrows storage and performance requirements"

Again, really nice article!

The more I learn, the more I know what I do not know
Blog: Things about Software Architecture, .NET development and T-SQL

How to Post Data/Code to get the best Help How to Post Performance Problems
Post #736471
Posted Wednesday, June 17, 2009 6:45 AM



Group: General Forum Members
Last Login: Monday, August 29, 2016 1:09 PM
Points: 13,999, Visits: 9,728
Actually, some of the uses I've seen for Cache ( are quite functional. It's a pain to work with, at least what little I've done and from what I've read, but as far as scalability, stability, security and performance, it seems to be a very solid product.

Rows and columns are very easy on the human mind. Breaking them down into normal forms takes training, discipline and experience, but the basic concept is easy. On the other hand, in the class object-model, does a door inherit characteristics from a car or is it the other way around? Do all doors have the same methods and properties? Does the presence of a lock on a door come about through polymorphism, or are locks their own object with their own methods and properties? Where does one even start?

Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Post #736477
Posted Wednesday, June 17, 2009 6:46 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, September 24, 2009 7:38 AM
Points: 33, Visits: 88
I've never been able to fully understand this drive, beyond the obvious. If you want object-relational access, write stored procedures.

It appears from the ORDB argument and from the primary arguments against stored procedures, that many of the folks that develop software and create the need for databases don't seem to understand that the data, although used by their application, perhaps even the primary driver for the storage of the information, are not the owners of that information. And the owner of that information may have other uses for that data beyond the scope of the original application. Enterprise Data Warehousing being one example. Manufacturing Automation, although less obvious, being another.

I can see where someone might create a wizard or some other technology similar to the query analyzer that will recommend or even automatically configure OR functions (.Net or Java?) or stored procedures, but to sacrifice orthoganility for the convenience of the developer--? Isn't that rather short-sighted?
Post #736479
Posted Wednesday, June 17, 2009 7:02 AM



Group: Administrators
Last Login: Today @ 6:58 AM
Points: 34,363, Visits: 18,580
rboggess (6/17/2009)
I've never been able to fully understand this drive, beyond the obvious. If you want object-relational access, write stored procedures.

For the most part I'm with you on this. Developers complain that it's too hard to work with, and I think they want to be able to store an object structure without having to worry about how it's stored. However it's the type of mapping they often have to do when working with the data on a screen, so I'm not sure why it's that hard.

And if it's too time consuming, why not have one person dedicated to writing the mapping in a data layer?

I just don't buy that it's a ton of time.

It is a knowledge investment, and maybe that's an issue. We don't have a way to quickly and easily train someone how to design a db.

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #736502
Posted Wednesday, June 17, 2009 7:04 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, May 13, 2013 5:16 AM
Points: 51, Visits: 33

I actually have nothing to add,just to say thanks,this has opened my eyes a little more,it just educated me....but I do wish I had these options say 3 months ago
Post #736505
Posted Wednesday, June 17, 2009 7:11 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, November 28, 2016 12:02 PM
Points: 379, Visits: 2,546
I am running the risk of stating nonsense here as honestly I have no real experience with object database implementations today.

To my possibly outdated knowledge the technical mechanism that is supporting object databases is visualization of local memory. Instead of having an object in local memory, you now indirectly work with an object that is persisted elsewhere. Thus a linked list or any other structure in local memory is persisted like that in the database...its persistent memory. This is what I got from it in the early 90s, so correct me if I am horribly off. The idea to me is just completely illogical from a quality and manageability point of view.

For me any persistent storage has to be:

* Decoupled from the processes acting on it;
* Has a state you can snapshot easily and independently verify;
* Accessible by many processes concurrently and handle operations in a way will not result in a corrupt state;
* Needs to be based on a low complexity model, thus only support a limited number of relation types between entities and data types;
* Does not require domain specific software for accessing the data and be maintainable by standardized software;

Any deviation from these things will result in errors accumulating and persisting and other problems. Say I as a programmer have everything I do in memory, persisted instantly for objects I tagged as needing this. Then the data and its relationships is tightly coupled to my algorithm that operates on it, if I use a linked list in memory, the data is structured that way. Now I made a mistake somewhere or I need to do an optimization..that likely will result in a change in both. But wait, what if there are multiple and different clients acting on the data....o are so horribly screwed.

On top of it, locality of reference will be totally out of whack. Algorithms that programmers use are in general NOT optimized to be efficient on remote virtual memory. They often aren't even optimized for locality at all, incurring penalties for doing accesses outside the processors level 1 cache. How this would translate to memory across a network, even further away from the processing in the CPU.....not good.

You end up with situation you will have to make mappers and wrappers for their past mistakes, in effect persisting the problem of an inadequate design or implementation. And because everyone programs to his own view, you can say goodbye to interoperability of software too. Code can't become any cleaner for any significant complex project...its all smoke and mirrors.

And that physics lab used an object database says nothing to me and that it is the biggest database in the world neither. It says nothing about scaling. Scaling is not just a function of size in storage, even a flat file with a fixed record lengths is scalable in that sense. Scaling applies to operations in the face of accumulating data, things like concurrent access and the efficiency of retrieval and mutation (the algorithms). Thus an Object database with algorithms that aren't going to be change, say they hash everything and this is persisted as the access structure in their database. And lets assume this suits the work they do perfectly, then yes it will be amazingly fast at retrieval, but that is a very specialized case.

I believe object databases by very definition are domain specific beasts and as a result will never find broad acceptance. I seen the OO hype in the early 90s and always felt people thought more if it then it actually proved to be. Now a new generation is at it doing exactly the same things but with improved technology at its base. I still haven't seen the fundamentals change and thus expect similar outcome.

Instead of learning how to do things right and understand the data they operate on, people take any solution that "promises" to take away that sore. OOP is always perceived as having this "promise", but I know the hard core OOP folks are pretty smart and put a lot more emphasis on design then the vast majority of developers do. They just want the promise of not having to do any design beforehand in the first place and start implementing quickly.

I would classify object databases as having the promise to do really rapid prototyping. But don't think they are a good idea to adopt as a replacement for actual software that is going to be used.

Now, prove me totally wrong! :)
Post #736513
Posted Wednesday, June 17, 2009 7:23 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, December 18, 2009 10:34 AM
Points: 3, Visits: 10
I can give you a better reason: the relational model is the most powerful adhoc querying system ever created. The output of a query is just another table, which can itself be queried; this recursiveness is not present in any object system I've seen. When an object database can query several classes of objects and present you with a brand new class of objects, they'll start to have something interesting. Until then, relational databases will rule wherever adhoc querying is, most businesses.

That said, for specific applications, alternative databases systems can do very well. For business applications, the relational database is usually the main point of it all, and websites are just front ends get data in and out. But for some projects, the website is the whole deal. For those, there are sometimes options to get dramatically better performance or scalability by using alternatives...object databases, graph databases like Neo4J, or distributed systems like Cassandra (runs part of Facebook), Scalaris, Google's Bigtable (available on Google App Engine), and Amazon's SimpleDB.
Post #736525
Posted Wednesday, June 17, 2009 8:01 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, July 7, 2016 7:07 AM
Points: 1,221, Visits: 240
Those who persist in advocating OODBs truly show either (1) a complete lack of practical experience in actual operational management of an implemented system, or (2) a failure to fully think out the basic principles of good design. I realize that statement is provocative, but many years of experience with both relational and object DBs lead me to make it.
IMHO, the single biggest problem with the OODB model is a complete lack of integrity control. An object has attributes which in turn may also be objects. I cannot tell you how many times I have seen circular ownership rings, where ten or fifteen levels in, an attribute object claims the original object as one of its attributes.
This is, admittedly, a product of poor design, but I have had many developers declare that it is a true model of their system's reality. What it actually does is create numerous untestable pathways in the supporting application code, and databases that go belly up through no fault of the DBA trying to keep that illogical DB afloat.
A nearly perfect example supporting in support of the case against the use of OODBs is the registry DB in MS Windows. Anyone who has much experience with Windows internals knows just how fragile and corruptible that puppy is. MS keeps multiple copies of the registry DB just so they have a reference point in support of attempts to fix it when it inevitably breaks. I am also convinces that that OODB underlayment is one of the reasons Windows is such "bloatware." In my experience, the application code built around OODBs has been some of the worst, and most inefficient code I've ever seen.
Relationals, on the other hand, can use built-in relational integrity checks to prevent this type of foul design from ever becoming reality. Yes, you can turn integrity checks off, but any decent DBA, faced with that need for performance reasons, would also write scripts to do periodic and frequent integrity checks. Another benefit of using the relational DB to store objects is the design discipline it imposes to accurately and logically define an object and its attributes. Tables are objects; columns are attributes; attributes that are also objects are foreign keys. What could be simpler? All of the esoteric object model terminology really boils down to just the previously stated basics.
Post #736578
« Prev Topic | Next Topic »

Add to briefcase 1234»»»

Permissions Expand / Collapse