SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Why Object Databases will always be Tomorrow's Technology


Why Object Databases will always be Tomorrow's Technology

Author
Message
Tony Davis
Tony Davis
SSC Eights!
SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)SSC Eights! (931 reputation)

Group: Administrators
Points: 931 Visits: 1160
Comments posted to this topic are about the item Why Object Databases will always be Tomorrow's Technology
Grant Fritchey
Grant Fritchey
SSC-Forever
SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)

Group: General Forum Members
Points: 40493 Visits: 32665
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 and SQL Server Execution Plans
Product Evangelist for Red Gate Software
Florian Reischl
Florian Reischl
Hall of Fame
Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)

Group: General Forum Members
Points: 3561 Visits: 3934
Nice article!

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

Again, really nice article!
Flo


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
GSquared
GSquared
SSC-Insane
SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)

Group: General Forum Members
Points: 23763 Visits: 9730
Actually, some of the uses I've seen for Cache (http://www.intersystems.com/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?

- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
rboggess
rboggess
SSC Journeyman
SSC Journeyman (81 reputation)SSC Journeyman (81 reputation)SSC Journeyman (81 reputation)SSC Journeyman (81 reputation)SSC Journeyman (81 reputation)SSC Journeyman (81 reputation)SSC Journeyman (81 reputation)SSC Journeyman (81 reputation)

Group: General Forum Members
Points: 81 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?
Steve Jones
Steve Jones
SSC Guru
SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)SSC Guru (63K reputation)

Group: Administrators
Points: 63464 Visits: 19115
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
My Blog: www.voiceofthedba.com
DangerMouseKaBoom
DangerMouseKaBoom
SSC Journeyman
SSC Journeyman (77 reputation)SSC Journeyman (77 reputation)SSC Journeyman (77 reputation)SSC Journeyman (77 reputation)SSC Journeyman (77 reputation)SSC Journeyman (77 reputation)SSC Journeyman (77 reputation)SSC Journeyman (77 reputation)

Group: General Forum Members
Points: 77 Visits: 33
Hello,

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
peter-757102
peter-757102
SSC Eights!
SSC Eights! (845 reputation)SSC Eights! (845 reputation)SSC Eights! (845 reputation)SSC Eights! (845 reputation)SSC Eights! (845 reputation)SSC Eights! (845 reputation)SSC Eights! (845 reputation)SSC Eights! (845 reputation)

Group: General Forum Members
Points: 845 Visits: 2559
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 shit....you 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! Smile
Dennis Puliwingeefarger
Dennis Puliwingeefarger
SSC Rookie
SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)

Group: General Forum Members
Points: 27 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 important...ie., 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.
Irish Flyer
Irish Flyer
Ten Centuries
Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)

Group: General Forum Members
Points: 1307 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.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search