Get real. This has nothing to do with Oracle's license price which incidentally they have lots of competition on from Mickeysoft. All of the license costs are incidental to the real price of a system.
New technology only gets adopted where it makes both economic and technical sense.
In reality economic and technical judgments are just two different ways of assessing the same thing. ODBMSs only get used where the data modeling and/or performance requirements make disproportionate subjective sense to the decision maker and they only have traction in applications long term where the subjective judgment maps to the objective (where the original decision maker's successor sees more good then harm in the fancy technical solution he/she inherits). Often the ODBMS is in effect competing with both a RDBMS and a commercial UNIX vendor since "throw more hardware at it" is a lot more acceptable solution to performance problems then anything as wild as an ODBMS. Linux and ODBMSs are natural pairings since they both make obvious economic sense but appear risky to business types.
The easiest cases are those where only a lunatic would think of using a relational system followed quickly by places where relational has already failed and the project is too important to abandon. The interesting thing is that ODBMS vendors can actually survive and in some cases prosper farming the rocky land left to them by the accepted RDBMS wisdom. Adverse times lead to rapid and arduous natural selection rewarding the fast & smart and killing the opposite. Hard times are good for the breed, unless they kill it off:-).
Thanks for coming out of the closet, always good to associate a name with a thought
-------------
I do not suggest that there are no uses for ODBMS systems. Certainly the example you give for CAD systems is good.
Yes, the evaluations I did were circa 1997. It's quite possible that better things have come since then. However, I have also interviewed a couple of engineers from Versant and their description of their systems left a lot to be desired - of course that could just be them.
-------------
Would be unfair for me to comment
-------------
I'm sure my employer uses/resells ODBMS systems somewhere. Big deal.. if my comments suggested that I think ODBMS systems will fade away - I don't. I just think to suggest that they will replace relational systems is stupid. I think we both agree there.
-------------
yup
-------------
I agree with a lot of what you say.. however:
An Object Database is a far more general solution, it is childs play to make an ODBMS pretend to be an RDBMS the opposite is what is hard.
This is laugable ! Yes, it's child's play to get an ODBMS support "relational" operations - but it's impossible to support relational operations in any efficient manner even coming close to what a relational engine can do.
--------------
No argument. I think you misunderstood me or hoped the audience would. If we grant that these two classes of system "R" and "O" are both useful for different purposes. We can also grant that each of them might be able to pretend to fill the others shoes (at least in marketing). I'm not arguing that anybody would use an "O" where an "R" would serve, but you seem to be arguing the opposite. You guys are going to be making those rows and columns go fast till kingdom come. Oh, and anything you can stuff into them as well.
---------------
Yes I'm biased, but I also have the ability to view engineeringproblems with objectivity.
--------------
I'll grant you probably believe this.
--------------
I submit that anybody who thinks performance isn't an important consideration for a relational system doesn't really understand the business and what relational customers want.
---------------
Change the word "relational" above to "Object" and you have my response.
---------------
We aren't really trying to compete with you if you are providing persistence for objects in an interactive application for CAD design.
--------------
Or anyplace else you can't make it work. If we have a disagreement (not sure we do), it is how prevalent and how soon the places relational won't work are. You remind me of a eunuch trying to convince a whole man of the benefits of castration "you don't really need those things":-). Marketing trumps technology, the big dominate the little, hay ask Bill Gates if you don't believe me. Marketing can't make iron float, it can just make most of the folks think that it does.
ODBMS have three classes of prospect customers:
1. Folks who were building their own Object DBMS or Caching systems, find it hard and want to buy vs make.
2. Folks who were trying to make ORDBMS scale, failed, didn't loose their job and decided that they needed to think out of the box.
3. And folks who want to use ODBMS because they are cool (read the original post)
The 1s are a nice market but nothing the likes of Oracle or Microsoft would bother with, the 3s shouldn't be left alone with something as sharp as an ODBMS read "But Performance is where ObjectStore stinks!" By Matt Barnson on this thread if you want an example. The interesting thing is that the number and frequency of 2s is growing. RDBMS marketing is force fitting a solution into a lot of situations where it doesn't make any sense. Nobody can defy gravity forever.
---------------
We are competing with you in caching solutions for web applications. I strongly believe that an ODBMS solution isn't scalable for a high-volume web application.
--------------
Do you think Amazon.com is a high-volume web application?
--------------
You might get some performance wins when your load is low, but one thing you have to understand is the difference between performance and scalability. How on earth do you plan to support shared-nothing (or shared-disk) parallelism for instance ?
-------------
Well since our caching architecture is essentially a shared-nothing system we map to them rather well. We aren't interested in hardware that costs millions, we are interested in doing the same job on a linix machine that costs thousands and we can do it.
-------------
The pure ODBMS market will definitely survive. How many vendors will be left, I'm not sure.
--------
full disclosure, I work for a ODBMS vendor, even worse I'm a marketing/business type (well with an engineering history) at an ODBMS vender.
Now for the 3 people who are still reading. It may surprise you but I and we (my company) agree with this RDBMS working coward to a large degree.
The premise of the parent article that positions RDBMSs and ODBMSs as direct alternatives for the same applications is flawed IMO. The fact is we make most of our sales on applications where we are replacing or competing with home grown database or caching solutions. If an RDBMS and an ODBMS are head to head technical competitors at the end of a prospect evaluation, one of them is in the wrong place.
Somebody will ask "Well both RDBMS and ODBMS are in the business of managing getting bits on and off disks enforcing ACID properties, what can be so different about the ODBMS applications that they can't use an RDBMS?" There is a simple answer. Performance and data model complexity, sometimes both. ODBMS's sell to customers who are modeling things that are so interrelated and complex that the task of transforming them at all to make them persistent and to share them among multiple users transactionally is inconceivable. Real time financial risk management systems, derivatives, simulation, optimization systems, document storage, Teleco network management, ECAD, CASE, CAD all examples. Do you think Intel is storing the designs, simulations and test systems for it's next chip in Oracle? How many people at once can work on the design for a chip with millions of transistors? Just one?
Also ODBMS are often the solution of choice where multi-tier application performance is gated by the time needed to access backend data sources (mainframe,Relational,legacy, etc). Once it becomes necessary for performance reasons to store, cache or warehouse data (think of it as work in progress inventory) in an intermediate datastore somewhere in the middle tier for, ODBMS's have a big advantage, the user by definition has a throughput problem, and the ODBMS will be a lot faster because the middle tier application will be based on components EJB, CORBA, using OO development languages. Application servers scale logic/behavior execution but if they are waiting on a query to the backend it won't matter how fast they execute.
Do I think these markets are as large and valuable as the market that RDBMS's address? No
Do I think they are large and growing and are on the cutting edge of new systems being automated?
YES
We stopped competing with RDBMS's about the time the products became mature enough to use. Say 1995.
Most of you have probably interacted with an ODBMS today, you just don't know it.
All of this cowards technical wacks, query languages, physical vs logical storage structure, gee RDBMSs are really good at some stuff duhh. Mostly these are comments on implementation details probably from the immature ODBMS he looked at in 1995. Some of them he is right about.
Take my word for it if you can use an RDBMS to solve your problem you probably should. Just don't assume that everybody has the same problem or that you won't have new *harder* problems in the future. The world is complex and most of it isn't automated and the parts that are automated are mostly the easy parts. Just common sense.
As far as the wonders of object/Relational highbred systems all I can say is, to a man with a hammer all the world is a nail. You can get screws to go in with a hammer but a screwdriver is more effective and more in keeping with the screw's purpose. You can also hammer in nails with a screw driver but a hammer is more effective. ODBMS companies all use RDBMS for CRM and accounting systems. RDBMS vendors may not know admit it but they are using (sometimes selling) ODBMS based applications as well. By the time ORDBMS systems are really competitive with ODBMS they *will* be ODBMSs. An Object Database is a far more general solution, it is childs play to make an ODBMS pretend to be an RDBMS the opposite is what is hard. General solutions can't be optimized for specific usage, because they are general. By the time the relational companies are done building ORDBMS that really compete with us O vs R will be a distinction without a difference. Change is slow and it takes a long time to build good, mature large software systems. Gee I bet some of you might already know this.
As far as all ODBMS companies going out of business, we have been around for 13 years and we are a lot larger then most people expect us to be. Even better, we don't have much (real) competition for the needs we address. We'll be around and improving.
Slashdot Mirror
Get real. This has nothing to do with Oracle's license price which incidentally they have lots of competition on from Mickeysoft. All of the license costs are incidental to the real price of a system.
:-).
New technology only gets adopted where it makes both economic and technical sense.
In reality economic and technical judgments are just two different ways of assessing the same thing. ODBMSs only get used where the data modeling and/or performance requirements make disproportionate subjective sense to the decision maker and they only have traction in applications long term where the subjective judgment maps to the objective (where the original decision maker's successor sees more good then harm in the fancy technical solution he/she inherits). Often the ODBMS is in effect competing with both a RDBMS and a commercial UNIX vendor since "throw more hardware at it" is a lot more acceptable solution to performance problems then anything as wild as an ODBMS. Linux and ODBMSs are natural pairings since they both make obvious economic sense but appear risky to business types.
The easiest cases are those where only a lunatic would think of using a relational system followed quickly by places where relational has already failed and the project is too important to abandon. The interesting thing is that ODBMS vendors can actually survive and in some cases prosper farming the rocky land left to them by the accepted RDBMS wisdom. Adverse times lead to rapid and arduous natural selection rewarding the fast & smart and killing the opposite. Hard times are good for the breed, unless they kill it off
Oh, I work for an ODBMS vendor.
Thanks for coming out of the closet, always good to associate a name with a thought
.. if my comments suggested that I think ODBMS systems will fade away - I don't. I just think to suggest that they will replace relational systems is stupid. I think we both agree there.
.. however:
:-). Marketing trumps technology, the big dominate the little, hay ask Bill Gates if you don't believe me. Marketing can't make iron float, it can just make most of the folks think that it does.
-------------
I do not suggest that there are no uses for ODBMS systems. Certainly the example you give for CAD systems is good.
Yes, the evaluations I did were circa 1997. It's quite possible that better things have come since then. However, I have also interviewed a couple of engineers from Versant and their description of their systems left a lot to be desired - of course that could just be them.
-------------
Would be unfair for me to comment
-------------
I'm sure my employer uses/resells ODBMS systems somewhere. Big deal
-------------
yup
-------------
I agree with a lot of what you say
An Object Database is a far more general solution, it is childs play to make an ODBMS pretend to be an RDBMS the opposite is what is hard.
This is laugable ! Yes, it's child's play to get an ODBMS support "relational" operations - but it's impossible to support relational operations in any efficient manner even coming close to what a relational engine can do.
--------------
No argument. I think you misunderstood me or hoped the audience would. If we grant that these two classes of system "R" and "O" are both useful for different purposes. We can also grant that each of them might be able to pretend to fill the others shoes (at least in marketing). I'm not arguing that anybody would use an "O" where an "R" would serve, but you seem to be arguing the opposite. You guys are going to be making those rows and columns go fast till kingdom come. Oh, and anything you can stuff into them as well.
---------------
Yes I'm biased, but I also have the ability to view engineeringproblems with objectivity.
--------------
I'll grant you probably believe this.
--------------
I submit that anybody who thinks performance isn't an important consideration for a relational system doesn't really understand the business and what relational customers want.
---------------
Change the word "relational" above to "Object" and you have my response.
---------------
We aren't really trying to compete with you if you are providing persistence for objects in an interactive application for CAD design.
--------------
Or anyplace else you can't make it work. If we have a disagreement (not sure we do), it is how prevalent and how soon the places relational won't work are. You remind me of a eunuch trying to convince a whole man of the benefits of castration "you don't really need those things"
ODBMS have three classes of prospect customers:
1. Folks who were building their own Object DBMS or Caching systems, find it hard and want to buy vs make.
2. Folks who were trying to make ORDBMS scale, failed, didn't loose their job and decided that they needed to think out of the box.
3. And folks who want to use ODBMS because they are cool (read the original post)
The 1s are a nice market but nothing the likes of Oracle or Microsoft would bother with, the 3s shouldn't be left alone with something as sharp as an ODBMS read "But Performance is where ObjectStore stinks!" By Matt Barnson on this thread if you want an example. The interesting thing is that the number and frequency of 2s is growing. RDBMS marketing is force fitting a solution into a lot of situations where it doesn't make any sense. Nobody can defy gravity forever.
---------------
We are competing with you in caching solutions for web applications. I strongly believe that an ODBMS solution isn't scalable for a high-volume web application.
--------------
Do you think Amazon.com is a high-volume web application?
--------------
You might get some performance wins when your load is low, but one thing you have to understand is the difference between performance and scalability. How on earth do you plan to support shared-nothing (or shared-disk) parallelism for instance ?
-------------
Well since our caching architecture is essentially a shared-nothing system we map to them rather well. We aren't interested in hardware that costs millions, we are interested in doing the same job on a linix machine that costs thousands and we can do it.
-------------
The pure ODBMS market will definitely survive. How many vendors will be left, I'm not sure.
--------
Well all I need is one in fact I prefer one.
Pax
Henry
full disclosure, I work for a ODBMS vendor, even worse I'm a marketing/business type (well with an engineering history) at an ODBMS vender.
Now for the 3 people who are still reading. It may surprise you but I and we (my company) agree with this RDBMS working coward to a large degree.
The premise of the parent article that positions RDBMSs and ODBMSs as direct alternatives for the same applications is flawed IMO. The fact is we make most of our sales on applications where we are replacing or competing with home grown database or caching solutions. If an RDBMS and an ODBMS are head to head technical competitors at the end of a prospect evaluation, one of them is in the wrong place.
Somebody will ask "Well both RDBMS and ODBMS are in the business of managing getting bits on and off disks enforcing ACID properties, what can be so different about the ODBMS applications that they can't use an RDBMS?" There is a simple answer. Performance and data model complexity, sometimes both. ODBMS's sell to customers who are modeling things that are so interrelated and complex that the task of transforming them at all to make them persistent and to share them among multiple users transactionally is inconceivable. Real time financial risk management systems, derivatives, simulation, optimization systems, document storage, Teleco network management, ECAD, CASE, CAD all examples. Do you think Intel is storing the designs, simulations and test systems for it's next chip in Oracle? How many people at once can work on the design for a chip with millions of transistors? Just one?
Also ODBMS are often the solution of choice where multi-tier application performance is gated by the time needed to access backend data sources (mainframe,Relational,legacy, etc). Once it becomes necessary for performance reasons to store, cache or warehouse data (think of it as work in progress inventory) in an intermediate datastore somewhere in the middle tier for, ODBMS's have a big advantage, the user by definition has a throughput problem, and the ODBMS will be a lot faster because the middle tier application will be based on components EJB, CORBA, using OO development languages. Application servers scale logic/behavior execution but if they are waiting on a query to the backend it won't matter how fast they execute.
Do I think these markets are as large and valuable as the market that RDBMS's address? No
Do I think they are large and growing and are on the cutting edge of new systems being automated?
YES
We stopped competing with RDBMS's about the time the products became mature enough to use. Say 1995.
Most of you have probably interacted with an ODBMS today, you just don't know it.
All of this cowards technical wacks, query languages, physical vs logical storage structure, gee RDBMSs are really good at some stuff duhh. Mostly these are comments on implementation details probably from the immature ODBMS he looked at in 1995. Some of them he is right about.
Take my word for it if you can use an RDBMS to solve your problem you probably should. Just don't assume that everybody has the same problem or that you won't have new *harder* problems in the future. The world is complex and most of it isn't automated and the parts that are automated are mostly the easy parts. Just common sense.
As far as the wonders of object/Relational highbred systems all I can say is, to a man with a hammer all the world is a nail. You can get screws to go in with a hammer but a screwdriver is more effective and more in keeping with the screw's purpose. You can also hammer in nails with a screw driver but a hammer is more effective. ODBMS companies all use RDBMS for CRM and accounting systems. RDBMS vendors may not know admit it but they are using (sometimes selling) ODBMS based applications as well. By the time ORDBMS systems are really competitive with ODBMS they *will* be ODBMSs. An Object Database is a far more general solution, it is childs play to make an ODBMS pretend to be an RDBMS the opposite is what is hard. General solutions can't be optimized for specific usage, because they are general. By the time the relational companies are done building ORDBMS that really compete with us O vs R will be a distinction without a difference. Change is slow and it takes a long time to build good, mature large software systems. Gee I bet some of you might already know this.
As far as all ODBMS companies going out of business, we have been around for 13 years and we are a lot larger then most people expect us to be. Even better, we don't have much (real) competition for the needs we address. We'll be around and improving.
Henry Parnell