OO-DBMS
-
Alas, I had somewhat the same experience. When we were using GemStone/S, many potential customers asked what database we were using for out back end. They had no need nor intention of querying the data directly, but they wanted warm fuzzies.
JLengi wrote:
had no need nor intention of querying the data directly
Were you selling an application (singular app) or a system? Because that data, far as I can tell, represents and application by itself. Which means that there is an operation cost with it. Which the customer, not you, would be providing. If they were an Oracle shop then they would have already had the operational support in place to support Oracle.
-
Remind me not to apply for a job at your place. We'll both be happier that way.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
Matthew Faithfull wrote:
Remind me not to apply for a job at your place. We'll both be happier that way.
Perhaps. I am certainly not a fan of developers that think that over-engineering based on fantasy business scenarios in the far future is a good thing.
-
I wonder if you are having the same conversation I am having. I didn't say anything about putting behavior in the database. But that's kind of the point of an OODBMS, isn't it? If you can transparently persist your business objects as they are, then you don't need to worry about the interface between your application tier and your data tier. And there are serious advantages to executing your behavior as close to your data as possible, chief among them being performance. Fewer transformations in the case of RDBMSs. And less chattiness between tiers in the case of both RDBMSs and OODBMSs. There will almost inevitably be a proliferation of paths to the data. The "closer to the metal" your business logic is, the fewer places it will need to be implemented, and the less likely your validation/integrity rules will get inadvertently bypassed.
JLengi wrote:
I wonder if you are having the same conversation I am having. I didn't say anything about putting behavior in the database.
I quoted what I responded to. If didn't mean that the you really need to re-state/re-phrase the following because it certainly seems to suggest that a OO database has behavior. "OODBMSs are far more flexible and RDBMSs.... One of the strengths of OO is its ability to model and use real-world data and behavior."
JLengi wrote:
If you can transparently persist your business objects as they are, then you don't need to worry about the interface between your application tier and your data tier.
I would certainly be interested in seeing that. Having used many databases, many types of abstractions and several OODBMs, I have certainly never seen that. I can suppose however that smaller simpler applications might have that feature. But I don't work on applications like that.
JLengi wrote:
And there are serious advantages to executing your behavior as close to your data as possible
I can agree with that. Of course the problem is that in complex systems it is often not possible to centralize even a majority of the business logic in one place. So it means little.
JLengi wrote:
chief among them being performance.
Nope. The only time I see performance problems that are based on the context you are suggesting it is because of design and architecture errors.
JLengi wrote:
and the less likely your validation/integrity rules will get inadvertently bypassed.
Can't say that I have ever seen that happen. Certainly it can't happen with integrity rules in a relational database.
-
JLengi wrote:
had no need nor intention of querying the data directly
Were you selling an application (singular app) or a system? Because that data, far as I can tell, represents and application by itself. Which means that there is an operation cost with it. Which the customer, not you, would be providing. If they were an Oracle shop then they would have already had the operational support in place to support Oracle.
The database was GemStone/S. We were a VAR and licensed and packaged it with the application. We provided tech support for database issues along with application issues. No administration was required after installation. Hot backups were automated, but the customer was responsible for archiving the backup files, if desired.
-
Matthew Faithfull wrote:
I used to work with an alternative database product, Multi dimensional OLAP, No SQL and the biggest problem in selling it was that managers install Oracle or SQL Server for the same reason they used to install IBM. The problem was not that it didn't work, it destroyed Oracle by 2 orders of magnitude in many applications but buyers wouldn't look at it because of there exisiting commitment to and investment in SQL technology.
Nope. What you are doing is relating some sales to the market as a whole. For example you are specifically comparing only two commercial products while ignoring those that are free. And business managers do in fact like free products.
-
Matthew Faithfull wrote:
Remind me not to apply for a job at your place. We'll both be happier that way.
Perhaps. I am certainly not a fan of developers that think that over-engineering based on fantasy business scenarios in the far future is a good thing.
-
Judah Himango wrote:
so that writes are fast and reads are slow (usually requiring multiple joins or multiple queries, or both).
So you are claiming that that is the idiom needed for NMS collection system which collects statistics from a vast array of elements for a large corporation? Say where the TPS could exceed 100,000? And where data is accessed solely via summarized static aggregations (with a trivial amount of drill down)?
-
JLengi wrote:
I wonder if you are having the same conversation I am having. I didn't say anything about putting behavior in the database.
I quoted what I responded to. If didn't mean that the you really need to re-state/re-phrase the following because it certainly seems to suggest that a OO database has behavior. "OODBMSs are far more flexible and RDBMSs.... One of the strengths of OO is its ability to model and use real-world data and behavior."
JLengi wrote:
If you can transparently persist your business objects as they are, then you don't need to worry about the interface between your application tier and your data tier.
I would certainly be interested in seeing that. Having used many databases, many types of abstractions and several OODBMs, I have certainly never seen that. I can suppose however that smaller simpler applications might have that feature. But I don't work on applications like that.
JLengi wrote:
And there are serious advantages to executing your behavior as close to your data as possible
I can agree with that. Of course the problem is that in complex systems it is often not possible to centralize even a majority of the business logic in one place. So it means little.
JLengi wrote:
chief among them being performance.
Nope. The only time I see performance problems that are based on the context you are suggesting it is because of design and architecture errors.
JLengi wrote:
and the less likely your validation/integrity rules will get inadvertently bypassed.
Can't say that I have ever seen that happen. Certainly it can't happen with integrity rules in a relational database.
- I don't want to belabor the obvious, but "OODBMS" != "OO". I said exactly what I meant. No need to assume otherwise. 2) One of the "smaller simpler" applications on which I worked (for 13 years) was a model-based systems engineering tool. It had an ERA schema editor and database editor (allowing customers to capture and establish traceability amongst their requirements, system behavior, components, etc.), supported multiple concurrent projects with different schemata and schema migration, supported inheritance, included a diagram framework (to dynamically generate customizable hierarchy, ERA, physical block, functional flow, and IDEF0 diagrams from the system model), had a scripting language and IDE, had customizable reports and a web portal based on the scripting language, had a graphical discrete event simulator (to execute system behavior), and supported project-, entity-, and attribute-level security. When one person edited the data, other concurrent users could see their diagrams update in real-time, and vice-versa. All this was done in Smalltalk by 3 to 5 developers using the GemStone/S OODBMS and app server. Shall I go on? What, exactly, do you work on? 3) I am not suggesting that a complex system or system of systems has to have all its business logic in one place, but rather that business logic should run closer to the data on which it operates. This is loose coupling on an architectural level. Really, its a foundation of SOA. Failure to observe this tenet IS a design/architecture problem and often DOES result in poor performance. 4) I write real software, and real software has bugs, which sometimes include the violation of validation/integrity rules. I've never seen a system in which RDBMS constraints alone were used to prevent all invalid data conditions. Besides, are you arguing for or against behavior in the DB?
-
Marc Clifton wrote:
Furthermore, OO all too often ends up representing more how the programmer wants to work with the data than the actual true relationships of the data
However to be fair that is often how data modeling ends up represented in the database as well. Especially with Agile.
Marc Clifton wrote:
All those inheritance graphs
Not sure to exactly what you are referring but if that refers to either OO database base, or data model or even OO programming and where "all" means a whole lot then there is something wrong with the design. None of the mentioned items should have a lot of inheritance. That suggests design problem where a developer thinks that an Employee and Sales Contact are both People rather than recognizing that there is only Person with different properties.
How does Agile contribute to bad design? PRINCIPLES BEHIND THE AGILE MANIFESTO #9: Continuous attention to technical excellence and good design enhances agility. It sounds like you and Marc both dislike inheritance. I, on the other hand, have run into many more problems with too little inheritance than with too much. It's a tool that can be used correctly, used incorrectly, or not used at all.
-
Marc Clifton wrote:
There's reason enough to answer "both",
One should use inheritance only when it is required. Thus most of the time one shouldn't use it.
-
JLengi wrote:
there are many applications that could and should use them but don't
Nope. For applications that persist data there are a very large number for which it doesn't matter how they persist it. The business is too small, too fragmented and/or to disorganized for it to matter how they persist it. Of the remainder they have specific functional needs which often center around 'performance'. Differing business categories relegate how performance can be best achieved but regardless what the core business a majority of those domains are still dependent on customers. And there is a vast array of business products with can be used via the relational model and with little or no work and used to drive revenue. Which is what businesses care about.
JLengi wrote:
The DBMS landscape has not reached equilibrium and is currently shifting away from relational and ACID
Presumably you have some actual data to demonstrate that.
And yet there are still many OODBMSs and a growing number of other no-SQL DBMSs and a large number of applications that use them to good effect. You also seem to be forgetting about government/defense/intelligence customers. They're about solving problems, not driving revenue. Businesses, too, if they want to survive and grow, need to solve problems better than their competitors, which means they need to use the best and/or simplest tools for the job, which aren't always relational. Just because something has market share doesn't mean it's the best. (How did Windows get to be the dominant OS?) My opinions expressed here are based on my experience and research. I am happy to pit my credibility against yours.
-
As we love OO designs in other fields then why did Object-oriented DBMS are not popular?
1010111011
It is a combination of many things including: 1) We want someone to turn to if something goes wrong. And most OO database projects don't have a company standing behind the product. 2) We want proven scalability. There are plenty of people who can help you scale out many of the various SQL based databases. 3) We end up wanting reports based on the natural relationships. Often these reports live their own life outside the original program. 4) We often find that we have programs that interact with related data, but don't want to drag code from the related programs into each other.
-
And yet there are still many OODBMSs and a growing number of other no-SQL DBMSs and a large number of applications that use them to good effect. You also seem to be forgetting about government/defense/intelligence customers. They're about solving problems, not driving revenue. Businesses, too, if they want to survive and grow, need to solve problems better than their competitors, which means they need to use the best and/or simplest tools for the job, which aren't always relational. Just because something has market share doesn't mean it's the best. (How did Windows get to be the dominant OS?) My opinions expressed here are based on my experience and research. I am happy to pit my credibility against yours.
JLengi wrote:
And yet there are still many OODBMSs and a growing number of other no-SQL DBMSs and a large number of applications that use them to good effect.
There are vast array of new technologies introduced every year. And the vast majority of those never stick. And I used a OODB product in 1994 so I would expect that if they were going to take over the world it would have already happened. Given that it was a product one can presume that it had been around for a while before that and the idea had been around before even that (because it wasn't the only OODB product at that time.)
JLengi wrote:
You also seem to be forgetting about government/defense/intelligence customers. They're about solving problems, not driving revenue.
So including all small businesses in all developed countries what percentage of delivered applications from all applications fit into that category?
JLengi wrote:
Businesses, too, if they want to survive and grow, need to solve problems better than their competitors, which means they need to use the best and/or simplest tools for the job,
Specious and for the most part not true. The vast majority of businesses probably including your government example don't use objective criteria for defining "best". They use subjective criteria for almost all aspects of development. And probably the real basis of choice is because they had either a really good experience a middling experience or a horrible experience with a technology with no real understanding of that result, but make a decision based on that anyways.
JLengi wrote:
Just because something has market share doesn't mean it's the best. (How did Windows get to be the dominant OS?)
Which of course if true is the exact example that demonstrates the fallacy in your previous statement. Because of course MS succeeded because of sales not technology (regardless of the merits of the product.)
-
And what you are doing is relating some business managers to business managers as a whole. You inferred a generalization and then attempted to refute it with a more sweeping generalization.
JLengi wrote:
And what you are doing is relating some business managers to business managers as a whole. You inferred a generalization and then attempted to refute it with a more sweeping generalization.
Nope. I am basing it on market penetration. OODB have been around for at least 20 years with essentially zero penetration. In comparison OO development had made a significant impact on the market after 20 years.
-
The database was GemStone/S. We were a VAR and licensed and packaged it with the application. We provided tech support for database issues along with application issues. No administration was required after installation. Hot backups were automated, but the customer was responsible for archiving the backup files, if desired.
JLengi wrote:
The database was GemStone/S. We were a VAR and licensed and packaged it with the application. We provided tech support for database issues along with application issues.
That is not operational support.
JLengi wrote:
Hot backups were automated, but the customer was responsible for archiving the backup files, if desired.
And thus they were responsible for the operations.
-
- I don't want to belabor the obvious, but "OODBMS" != "OO". I said exactly what I meant. No need to assume otherwise. 2) One of the "smaller simpler" applications on which I worked (for 13 years) was a model-based systems engineering tool. It had an ERA schema editor and database editor (allowing customers to capture and establish traceability amongst their requirements, system behavior, components, etc.), supported multiple concurrent projects with different schemata and schema migration, supported inheritance, included a diagram framework (to dynamically generate customizable hierarchy, ERA, physical block, functional flow, and IDEF0 diagrams from the system model), had a scripting language and IDE, had customizable reports and a web portal based on the scripting language, had a graphical discrete event simulator (to execute system behavior), and supported project-, entity-, and attribute-level security. When one person edited the data, other concurrent users could see their diagrams update in real-time, and vice-versa. All this was done in Smalltalk by 3 to 5 developers using the GemStone/S OODBMS and app server. Shall I go on? What, exactly, do you work on? 3) I am not suggesting that a complex system or system of systems has to have all its business logic in one place, but rather that business logic should run closer to the data on which it operates. This is loose coupling on an architectural level. Really, its a foundation of SOA. Failure to observe this tenet IS a design/architecture problem and often DOES result in poor performance. 4) I write real software, and real software has bugs, which sometimes include the violation of validation/integrity rules. I've never seen a system in which RDBMS constraints alone were used to prevent all invalid data conditions. Besides, are you arguing for or against behavior in the DB?
JLengi wrote:
I don't want to belabor the obvious, but "OODBMS" != "OO". I said exactly what I meant. No need to assume otherwise.
I quoted exactly what you said. Up to you to rephrase not me.
JLengi wrote:
was a model-based systems engineering tool.
Which is, far as I know, one of the best niches for a OODB. That problem domain however is very, very small in the total development domain space.
JLengi wrote:
What, exactly, do you work on?
Last delivered system in production was handling $4 billion a year in credit card transactions with a measured TPS rate of 100 per server. The database problems there resolved around a failure to mentor less experienced developers in architecture and design.
JLengi wrote:
I am not suggesting that a complex system or system of systems has to have all its business logic in one place, but rather that business logic should run closer to the data on which it operates.
And I already said I agree with that ideal.
JLengi wrote:
Failure to observe this tenet IS a design/architecture problem and often DOES result in poor performance.
Then you have seen different problems than I have.
JLengi wrote:
I've never seen a system in which RDBMS constraints alone were used to prevent all invalid data conditions.
I didn't say that.
JLengi wrote:
Besides, are you arguing for or against behavior in the DB?
You tied the OODB to the definition of OO - not me.