OO-DBMS
-
CPallini wrote:
we really don't need OOP
FTFY
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. Those who seek perfection will only find imperfection nils illegitimus carborundum me, me, me me, in pictures
-
Probably because we don't need OO Databases (if we really need OOP is an open question to me). Moreover, SQL has good foundations and is widespread.
Veni, vidi, vici.
Is probably the same reason that nobody will ever use more than 640KB?
-
Is probably the same reason that nobody will ever use more than 640KB?
-
As we love OO designs in other fields then why did Object-oriented DBMS are not popular?
1010111011
I have been asked this question before, but fail to see why it continuously raises it's (very) ugly head. Relational database technology is the product of over seventy years (at least) of structured algorithmically sound research into holding human collected data. The mechanisms and languages which have evolved as part of that research are incredibly sound, and offer a fantastic, intuitive, and performant mechanism for handling human collected data sets. For that reason, a traditional RDBMS is the best product to deliver a data handling solution when dealing with human produced data. Object Orientation, as a programming paradigm is probably 20 years younger than relational DB's, and came about through the need to manage complex heirarchies in a manner which allowed the human mind to manage the complexities involved. The use of expanded types allowing real world readability to come into a machine parsed language allows developers to be much more productive. The study of patterns and frameworks show massive levels of improvement (in both creation and use) in OO and type-expandable languages, to the point where non-OO languages can struggle to even implement some types of framework. To a current developer who understands both paradigms well, the OO-DBMS may make sense as a route to allow a seamless integration of data with the programming above it, but the fact that both of these fields have progressed to where they are and arrived at very beneficial and computable outcomes means I am obliged to defend their seperation as beneficial, despite the fact that the integration code between well formed OO business and integration tiers and relational data is at best inelegant, and at worst downright counter productive. Having said all of that, I use embedded ODBMS for all internal or computer generated data (object serialisation, marshalling data, etc.) where I can, as it often struggles to be mapped to relational data pleasantly, whereas I've found that relational modelling is much better (quicker and more easily complete) for human produced data.
-
As we love OO designs in other fields then why did Object-oriented DBMS are not popular?
1010111011
Have you looked at the JDO Spec? In particular, check out the state-transition diagrams and tables culminating on p.67 of the latest version of the spec. It's just about the most beautiful thing I've ever seen. That's what a persistence mechanism should be. For 9 years, I used GemStone/S, a Smalltalk application server and OODBMS. The application on which I was working would not have been possible without it. We could run the same code on the client and the server, and each thread of execution could bounce between them, depending on where the behavior could run most efficiently. Objects cached in the client could be automatically refreshed when changes to their persistent images were committed. It supported indexing and had an OO query syntax. It had a clustering mechanism so that diverse objects that needed to be fetched together would be stored on the same page. And the fetching was configurable, so you could retrieve whatever piece of an object graph you needed in a single trip. For applications that can leverage features like that, an OODBMS will be more performant than a RDBMS. As others have said, applications that are heavy on aggregation, reporting, and doing CRUD operations on "rectangles" of data, should use an RDBMS. The general rule is that an applications affinity for an OODBMS is proportional to the complexity of its object model.
-
Monster Maker wrote:
As we love OO designs in other fields then why did Object-oriented DBMS are not popular?
Because I don't love OO designs. The concepts are restrictive and all too often inappropriately applied. A relational DB is simple and flexible, one doesn't care if a foreign key represents a "has a" or "is a kind of" relationship -it's simply a relationship. 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--think denormaliation. So, mapping a denormalized or otherwise bad OO design onto a relational DB is Not A Good Idea. Finally, given that I found very little use for OO other than UI controls and some limited abstractions, I can't imagine why I would think an OO-DBMS would be a useful thing. Interfaces are useful, classes are great as containers of behavior and state, and that's about it. All those inheritance graphs? X| Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My BlogSo your argument is that OO is bad because you do it badly? I would take the exact opposite position on just about every point. OODBMSs are far more flexible and RDBMSs. (Usually, you're not required to worry about or maintain the schema.) One of the strengths of OO is its ability to model and use real-world data and behavior. OO is generally more applicable to business objects than UI controls. And inheritance, if done properly, is a wonderful abstraction. In many cases where there is conditional logic--and in most cases where there is a type cast--inheritance would have clarified and simplified the code.
-
You don't need it. You might want to use it because you think it will best serve your requirement but there are many right ways to do something just as there are many wrong ways, grasshopper: experience tells you which is the best solution. KISS.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. Those who seek perfection will only find imperfection nils illegitimus carborundum me, me, me me, in pictures
-
As we love OO designs in other fields then why did Object-oriented DBMS are not popular?
1010111011
RDBMS are the industry standard, period, besides, no one has been fired for buying Oracle... :rolleyes:
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
Marc Clifton wrote:
all too often inappropriately applied
That's no reason not to love something! I've seen some very inappropriate database designs in my time -- but that's no reason for not loving SQL!
Marc Clifton wrote:
one doesn't care if a foreign key represents a "has a" or "is a kind of" relationship
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.
Marc Clifton wrote:
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--think denormaliation.
Again, isn't this down to poor design (assuming it's done badly)? There are plenty of good reasons to denormalise a database - but many more bad ones. Again, I've seen some appalling messes of database design, and of OO design - but it's the designer at fault not the tool (grin) I'm genuinely surprised at someone not finding use for OO. When I was first introduced to OO (many many years ago) I really couldn't see the point - but the more I was forced to use it, the more I liked it, to the point where I started thinking in OO design terms - and when that happens everything just clicks into place. I genuinely don't think I could write good, non OO code any more - I'd guess that you use classes and objects at a single level as containers for methods and properties and not much more? This isn't a criticism - I know you have a wealth of experience - I'd be interested in seeing how you develop non-OO software these days!
MVVM # - I did it My Way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
_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
-
So your argument is that OO is bad because you do it badly? I would take the exact opposite position on just about every point. OODBMSs are far more flexible and RDBMSs. (Usually, you're not required to worry about or maintain the schema.) One of the strengths of OO is its ability to model and use real-world data and behavior. OO is generally more applicable to business objects than UI controls. And inheritance, if done properly, is a wonderful abstraction. In many cases where there is conditional logic--and in most cases where there is a type cast--inheritance would have clarified and simplified the code.
JLengi wrote:
So your argument is that OO is bad because you do it badly?
No, my argument is that OO is bad because it doesn't correctly capture the real world.
JLengi wrote:
One of the strengths of OO is its ability to model and use real-world data and behavior.
Ah, that's where I disagree. The real world is a constantly changing environment of data, behavior, and relationships. One of the first things I learned about OO is that it is wonderfully appropriate when modeling extremely well defined and static relationships, and very poor, except in terms of abstractions, of modeling dynamic relationships. I can point to several records management systems I've worked on over the years that became calcified in their inability to adjust to new relationships in the data that the customer wanted to see, because OO was used originally to hardwire the customer's requirements 15 years ago, which of course have changed, and the database also reflected those hardwired initial conditions. If OO hadn't been used for those, what were then "real-world" data and behaviors, but instead a framework supporting dynamic data and relationships had been used (with sparse OO to support that), then the application could have continued to survive changing customer requirements.
JLengi wrote:
OO is generally more applicable to business objects than UI controls.
Again, I disagree, this time strongly. Business objects are not stable over time.
JLengi wrote:
And inheritance, if done properly, is a wonderful abstraction.
Agreement there. Interfaces are wonderful, and as you point out, conditional logic and type casts can be eliminated with proper OO modeling - that is one of its strengths. Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My Blog -
JLengi wrote:
So your argument is that OO is bad because you do it badly?
No, my argument is that OO is bad because it doesn't correctly capture the real world.
JLengi wrote:
One of the strengths of OO is its ability to model and use real-world data and behavior.
Ah, that's where I disagree. The real world is a constantly changing environment of data, behavior, and relationships. One of the first things I learned about OO is that it is wonderfully appropriate when modeling extremely well defined and static relationships, and very poor, except in terms of abstractions, of modeling dynamic relationships. I can point to several records management systems I've worked on over the years that became calcified in their inability to adjust to new relationships in the data that the customer wanted to see, because OO was used originally to hardwire the customer's requirements 15 years ago, which of course have changed, and the database also reflected those hardwired initial conditions. If OO hadn't been used for those, what were then "real-world" data and behaviors, but instead a framework supporting dynamic data and relationships had been used (with sparse OO to support that), then the application could have continued to survive changing customer requirements.
JLengi wrote:
OO is generally more applicable to business objects than UI controls.
Again, I disagree, this time strongly. Business objects are not stable over time.
JLengi wrote:
And inheritance, if done properly, is a wonderful abstraction.
Agreement there. Interfaces are wonderful, and as you point out, conditional logic and type casts can be eliminated with proper OO modeling - that is one of its strengths. Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My BlogMarc Clifton wrote: The real world is a constantly changing environment of data, behavior, and relationships. One of the first things I learned about OO is that it is wonderfully appropriate when modeling extremely well defined and static relationships, and very poor, except in terms of abstractions, of modeling dynamic relationships. I agree about the dynamic nature of the world. I disagree that OO can't model it. I spent a total of 15 years of my career working at two companies on two COTS product suites, one a family of model-based systems engineering tools, the other a family of knowledge management SDKs. In both cases, we used OO in all its glory to implement an entity-relationship-attribute (including attributed relationships) meta-model. Entities, relationship, and attributes were instances. The types/definitions of those entities, relationships, and attributes, were also instances. Entity definitions could even inherit from other entity definitions. Elegant and maintainable. I have also seen designs that suffer from the maladies you describe.
-
Marc Clifton wrote: The real world is a constantly changing environment of data, behavior, and relationships. One of the first things I learned about OO is that it is wonderfully appropriate when modeling extremely well defined and static relationships, and very poor, except in terms of abstractions, of modeling dynamic relationships. I agree about the dynamic nature of the world. I disagree that OO can't model it. I spent a total of 15 years of my career working at two companies on two COTS product suites, one a family of model-based systems engineering tools, the other a family of knowledge management SDKs. In both cases, we used OO in all its glory to implement an entity-relationship-attribute (including attributed relationships) meta-model. Entities, relationship, and attributes were instances. The types/definitions of those entities, relationships, and attributes, were also instances. Entity definitions could even inherit from other entity definitions. Elegant and maintainable. I have also seen designs that suffer from the maladies you describe.
JLengi wrote:
In both cases, we used OO in all its glory to implement an entity-relationship-attribute (including attributed relationships) meta-model.
Exactly! When it comes to meta-modeling, I think OO is a great solution. I've done very similar E/R/A systems in the past. Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My Blog -
As we love OO designs in other fields then why did Object-oriented DBMS are not popular?
1010111011
Monster Maker wrote:
As we love OO designs in other fields
Pretty sure that my hammer isn't OO. Neither is the keypad on my calculator. Nor for that matter is IP traffic. The idiom applies to a small set of real world solutions and databases are not one of those. For the vast majority of cases, the utility of objects in a database do not match the needs of processing data (not objects) in the database.
-
Probably because they don't play nicely with SQL. SQL is very often what management think they understand so it's an unarguable requirement. The ORM or Object Relational Mapping is the messy expensive compromise that lets you pretend you're dealing with an OO DBMS as a developer but allows SQL to contnue to be used.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
Matthew Faithfull wrote:
Probably because they don't play nicely with SQL. SQL is very often what management think they understand so it's an unarguable requirement
Wrong. Technologies that offer actual benefits are embraced rapidly across wide spectrums of development. Management seldom makes technology decisions unless that is their job (like a CTO.) Real business managers care about cost, delivery and sales. Technologies that do not provided benefit or which prove detrimental are rejected. And there are many more of those than successes. And it is easy to find examples of failures and successes. "Object Oriented Programming" itself is one of the success cases. CASE Tools as well as OO databases are ones that failed to gain any significance in the development realm because they do not provide benefits. And OO databases have had decades in which to gain acceptance and have not.
-
And here's one example of why we do need OOP in the real world. I'm currently refactoring a library of a few dozen classes. This job is taking approximately twice as long as it otherwise would because the original author although a undoubtedly a genius did not bother over much with that basic tennet of OOP encapsulation. The library is full of public data members and friend declarations so that whenever I change the internals of class I have to trawl the whole library fixing errors all over the place where code is diving into the internals of other classes and modifying unencapsulated data. Now just imagine how much fun I'm going to have when I want this code to be thread safe. +5 for OOP :)
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
Matthew Faithfull wrote:
And here's one example of why we do need OOP in the real world.
I don't see anything in that description that suggests it has anything to do with OOP. Poor implementation is poor implementation. If anything your description suggests a failure at process control which is a people problem not a technology problem. Or at least on might presume that if stringent code reviews had been in place the quality might have been better.
Matthew Faithfull wrote:
Now just imagine how much fun I'm going to have when I want this code to be thread safe.
That of course has absolutely nothing to do with OOP nor perhaps even process control. If the original app didn't need threads then it would have been unprofessional to write the code to support threads. The fact that requirements change over time is part of business and nothing more than how the real world works.
-
I used db4o[^], an object database, on a project a few years ago. Experience was mixed. What query language do you use? There wasn't a standard, and this object database had 3 different query languages. How do you handle unbounded result sets? Object databases have to guess how deep to load objects. It's kind of messy. That said, I find SQL terrible for today's apps: data is stored exactly once, so that writes are fast and reads are slow (usually requiring multiple joins or multiple queries, or both). That worked for 1970s when disk space was at a premium. Now it makes sense to optimize for reads; store the data multiple times if you need so that reads are blazing fast. Let writes be slow, since our applications tend to read far more than write. For these reasons, I'm using RavenDB[^]. It's a non-SQL database built for .NET developers. First class LINQ support, simple API, no tables or schemas needed. I like it.
My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
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)?
-
Monster Maker wrote:
As we love OO designs in other fields then why did Object-oriented DBMS are not popular?
Because I don't love OO designs. The concepts are restrictive and all too often inappropriately applied. A relational DB is simple and flexible, one doesn't care if a foreign key represents a "has a" or "is a kind of" relationship -it's simply a relationship. 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--think denormaliation. So, mapping a denormalized or otherwise bad OO design onto a relational DB is Not A Good Idea. Finally, given that I found very little use for OO other than UI controls and some limited abstractions, I can't imagine why I would think an OO-DBMS would be a useful thing. Interfaces are useful, classes are great as containers of behavior and state, and that's about it. All those inheritance graphs? X| Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My BlogMarc 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.
-
Marc Clifton wrote:
all too often inappropriately applied
That's no reason not to love something! I've seen some very inappropriate database designs in my time -- but that's no reason for not loving SQL!
Marc Clifton wrote:
one doesn't care if a foreign key represents a "has a" or "is a kind of" relationship
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.
Marc Clifton wrote:
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--think denormaliation.
Again, isn't this down to poor design (assuming it's done badly)? There are plenty of good reasons to denormalise a database - but many more bad ones. Again, I've seen some appalling messes of database design, and of OO design - but it's the designer at fault not the tool (grin) I'm genuinely surprised at someone not finding use for OO. When I was first introduced to OO (many many years ago) I really couldn't see the point - but the more I was forced to use it, the more I liked it, to the point where I started thinking in OO design terms - and when that happens everything just clicks into place. I genuinely don't think I could write good, non OO code any more - I'd guess that you use classes and objects at a single level as containers for methods and properties and not much more? This isn't a criticism - I know you have a wealth of experience - I'd be interested in seeing how you develop non-OO software these days!
MVVM # - I did it My Way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
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.
jschell wrote:
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.
That's where some of the ambiguity lies for me, and I remember pondering these issues a lot when first learning OO - should Employee and Sales Contact be treated as "is a kind of Person" or should they "have a" role: employee, sales contact, etc., (and of course, possibly multiple roles depending on their relationship to other entities.) There's reason enough to answer "both", as it depends on the circumstances. Ultimately, in my ROP articles by exploring the idea that the relationship itself is a first class denizen of the object world, capable of having its own properties. Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My Blog -
So your argument is that OO is bad because you do it badly? I would take the exact opposite position on just about every point. OODBMSs are far more flexible and RDBMSs. (Usually, you're not required to worry about or maintain the schema.) One of the strengths of OO is its ability to model and use real-world data and behavior. OO is generally more applicable to business objects than UI controls. And inheritance, if done properly, is a wonderful abstraction. In many cases where there is conditional logic--and in most cases where there is a type cast--inheritance would have clarified and simplified the code.
JLengi wrote:
OODBMSs are far more flexible and RDBMSs
Nonsense.
JLengi wrote:
One of the strengths of OO is its ability to model and use real-world data and behavior
Good point. Care to explain exactly what business behavior you are putting into your OO database?
JLengi wrote:
OO is generally more applicable to business objects than UI controls.
Which has little to do with persisted data. Just as, for example, it has nothing to do with sending it over IP.
JLengi wrote:
And inheritance, if done properly, is a wonderful abstraction
Yes. It is however a shame that it is often misused.
JLengi wrote:
In many cases where there is conditional logic--and in most cases where there is a type cast--inheritance would have clarified and simplified the code.
Which is something that I almost never see. And I certainly don't remember seeing much of it when I did procedural programming.