OO-DBMS
-
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.
-
_Maxxx_ wrote:
That's no reason not to love something!
Yes, you're point is well taken - thanks for the correction.
_Maxxx_ wrote:
If it's an HAS A it's a one-to-many relationship. If it's IS A KIND OF it's a many-to-one. So one does care- just using different terminology, really.
Another good point!
_Maxxx_ wrote:
I'm genuinely surprised at someone not finding use for OO.
I'm not saying it doesn't have its uses, it's just that over time I've found that my application of OO is becoming more and more restrictive - by choice. There are clearly many situations where abstraction is necessary in order to perform operations on "similar" objects. One of my concerns, especially having worked in records management for a few years, is the changing requirements and relationships between data and their representational constructs (classes) which led me to write a series of articles on Relationship Oriented Programming, exploring the idea of potentially very dynamic relationships.
_Maxxx_ wrote:
I'd guess that you use classes and objects at a single level as containers for methods and properties and not much more?
[a long answer] What I end up doing nowadays is a hybrid of OO, functional and event programming. While I still code in C#, I'm using classes, as you point out, as containers for methods and properties - though it's a semantic difference, I prefer to think of classes nowadays as simply managing state (the state of properties), thus the methods defined in those classes are simply there for supporting state change. That is not to say that a rich interaction between objects managing their state doesn't exist (UI state and model state are two good examples.) In fact, it does very much exist and I rely very much on events to propagate state changes to objects. It's interesting to see how small methods become when they are "simply" responsible for a state change and a corresponding event. The "work" that gets done becomes distributed across a variety of small components, each responsible for their own paradigm. The functional part comes in when I need something that does the "heavy lifting", if you will. This means that there are some computations (a general term, I'm not referring to just mathematics, but anything, like sorting a tree) that require work
I'd read that article, that's an interesting coding style, particularly the pros and cons. Also with a list of the most common functional programming ideas you use, tree sorts etc, because I just don't grok functional programming. It just seems too hard but a basic series of common functional programming patterns would be nice in English. When ever I've read other FP guides they immediately go into f(s 1 2) type statements and think it was written by a russian mathematician.
-
As we love OO designs in other fields then why did Object-oriented DBMS are not popular?
1010111011
Because OODB's are the answer to the wrong question. That question being "How can I as a developer who thinks procedurally force that onto a database management system so that I don't have to learn/understand SET based operations which are the foundation of the RDBMS model." Inagine how ridiculous it would sound to you if the RDBMS community had come up with an "Object Oriented" free alternative to the traditional programming language that allowed DBA's and DB Architects to write code without having to learn and more importantly, understand the Object-Oriented model of classes, inheritence and so on.