OO-DBMS
-
As we love OO designs in other fields then why did Object-oriented DBMS are not popular?
1010111011
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)
-
As we love OO designs in other fields then why did Object-oriented DBMS are not popular?
1010111011
-
As we love OO designs in other fields then why did Object-oriented DBMS are not popular?
1010111011
-
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:
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
-
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
-
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
-
As we love OO designs in other fields then why did Object-oriented DBMS are not popular?
1010111011
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
-
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
-
Aggregates Management do love their aggregates. Usually in report form. And guess what (most) OODBMS's suck at doing? Aggregates.
I was going to write: Performance. But I like your answer better.
Be excellent to each other. And... PARTY ON, DUDES! Abraham Lincoln
-
It's for general use. What makes you think otherwise? I'm using it at my startup company, at 3M on a big enterprise project, and on my animal rescue site. It's a general purpose database.
My Messianic Jewish blog: Kineti L'Tziyon My software blog: Debugger.Break() Judah Himango
-
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
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)
-
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')