OO-DBMS
-
Exactly, it's the lack of a standard query language that has crippled OO-DBMS to date. SQL sucks bigtime for many modern applications but it's standard. I'll have to take a look at RavenDB at some point. I've been waiting for a decent general purpose alternative DB.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
I've been very happy with Raven. First-class LINQ support is huge. Querying looks like this:
using (var session = db.OpenSession())
{
var bars = session.Query().Where(f => f.Name == "Bar");
}Storing objects is likewise easy:
using (var session = db.OpenSession())
{
var myFoo = new Foo(...);session.Store(myFoo);
session.SaveChanges();
}Notice I didn't have to deal with tables, schemas, stored procedures, joins, or any of the other mess we've had to deal with in SQL databases. It's optimized for fast reads. Super simple API. Transactional. Machine learning based on your query usage...all kinds of goodies. I've been very happy with it.
My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
-
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.
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)
-
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)
OOP does not solve every problem and it is too easy to go overboard and deviate from the primary, most basic principle of development: 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
-
OOP does not solve every problem and it is too easy to go overboard and deviate from the primary, most basic principle of development: 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
I would say OOP doesn't solve any problem but I've yet to come across a problem it didn't help me make a better solution for. I've seen a few too many apparently simple solutions to inherently difficult problems to believe that KISS is any better than OOP as a mantra. It's fine as another tool in the box to be used with caution and common sense.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
-
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)
-
That's exactly my point. OOP doesn't make the code work better it makes it easier to read, understand and modify. It makes it open to less intelligent people like me. It makes the code much more likely to survive and get reusued. In other words it makes the source code much better without making the object code much worse.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
-
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 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 Blog -
I would say OOP doesn't solve any problem but I've yet to come across a problem it didn't help me make a better solution for. I've seen a few too many apparently simple solutions to inherently difficult problems to believe that KISS is any better than OOP as a mantra. It's fine as another tool in the box to be used with caution and common sense.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
Matthew Faithfull wrote:
It's fine as another tool in the box to be used with caution and common sense.
That I can wholeheartedly agree with.
"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
-
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:
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')
-
That's exactly my point. OOP doesn't make the code work better it makes it easier to read, understand and modify. It makes it open to less intelligent people like me. It makes the code much more likely to survive and get reusued. In other words it makes the source code much better without making the object code much worse.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
Matthew Faithfull wrote:
It makes it open to less intelligent people like me
We Klingon Developers do not support less intelligent people ;P (actually we do not support people at all). You are far too intelligent to need OOP. If the code author wrote it following, for instance, structured programming guidelines, his code would have been accessible as well.
Veni, vidi, vici.
-
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.
CPallini wrote:
SQL has good foundations
hmm.. Codd, Date etc. put that to doubt. As Codd invented relational DB's he should know. Check Wiki's Criticism section for SQL to some links to more info. In fact many of the issues relating to the (misnamed) OO/RDB impedance are actually due to Oracle's failure to follow the Relational Model when designing SQL. Particularly the lack of proper support for Domains (RDB terminology, not app terminology).
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Exactly, it's the lack of a standard query language that has crippled OO-DBMS to date. SQL sucks bigtime for many modern applications but it's standard. I'll have to take a look at RavenDB at some point. I've been waiting for a decent general purpose alternative DB.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
Matthew Faithfull wrote:
but it's standard.
unless you want to store, as just one example, dates and times in your DB.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
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...