Nice story. The problem starts, when bizdev calls, and asks you to give them a report for customer X, product Y for December.
OO databases have their place, but most of them have one huge deficit. They are not database, but ACID storage kits for objects. There are some huge benefits for SQL databases: *) they are known beasts. Their properties get thought in university in most CS studies. With that I mean stuff like atomicity, transactions, concurrency. All these problems are more or less solved for relational databases. For OO dbs, the properties depend strongly on details of the exact database product you use. *) Accessibility. OO DB tend to be so called hierarchical databases. To take your example: obj.attr = [obj1, obj2, obj3]. Cool if I've got obj at hand. Not so cool when you've got got obj1, and need to answer the question what object refer to it. Basically, while SQL schemata are often optimized for certain access pattern, I can usually answer questions from the users by doing a custom query, that runs in acceptable time. For most OO DBs, I need to code up a script that extracts data. Take an example, a list of all customers that bought widget X. So either I need to touch all customers to find what they have bought, or the DB "schema/usage" needs to be changed to include backlinks from ProductX. Now if the app does keep this backlinks cool. If not, I'm fucked, because instead of a report for bizdev, I need to write them back that I need to change the application, and after that I need to fix the database to the new "format". *) that was mentioned above, but it's so important, I'll mention it again: concurrent access. Basically, ORM try to make a nice interface for an ugly world. Good. OODB are nativly nice. Trouble is that the world most often is not a nice place to be. And with a hierarchical database, querying data in any unexpected way breaks down badly. (And, I can write good OO code. And there are places for an OO db. Albeit in most business you will probably end extracting the data to a relation db just for business intelligence usage anyway.) Andreas * John M Camara <[EMAIL PROTECTED]> [070127 04:10]: > > > > On Jan 26, 3:19 am, Sylvain Hellegouarch <[EMAIL PROTECTED]> wrote: > >I think offering the use of OODBMS would be a good idea if their state > > was in a better shape. Having a storage like Durus is a good thing but > > is it enough? Do you have any standard query language? > > Sorry if this ends up being a double post. > > Object oriented databases don't need a standard query language. That's > right they don't need a query language. I know this may sound strange > for all those people you have this believe that a database can only be > a database if it acts like a relational database but that belief is > just plain wrong. > > I want to make sure that before I continue that you know that I'm not > against relational databases. I just prefer to use the right type of > database for a given project. Sometimes a relational database is the > right one for a project but in other times an object oriented one is > the right fit. The problem is that most people are only aware of > relational databases and just use them as that's all they know. If > they do try an object orient database it's usually after using a > relational database and then they can't understand why it doesn't have > a query language. They end up feeling like a fish out of water and > come to the conclusion that OO databases are useless. > > Now sometimes people end up using relational databases for the wrong > type of projects. When the do so they end up struggling with > performance issues of have to write an amazing amount of code or very > complex queries in order to successfully use the database for the > project. > > Over the years relational databases become more and more complicated in > order to handle these projects that don't fit well with relational > databases. They add these complexities so that they can continue to > sell their kool-aid that relational databases are the King of databases > and that can handle all you persistent storage needs. > > Another problem is created by ORMs. ORMs try to solve the impedance > mismatch that exists between object orient programming and relational > databases. Now don't get me wrong, ORMs are great for projects that > are a good fit for relational databases as they bridge the gap build > between the OO code and the database. The issue with ORMs is that it > makes it easier to connect OO code with the relational database that > some applications that would be so difficult to connect to a relational > database become possible. So you end up with applications that would > be a natural fit for an OO database doing all kind of abuse to a > relational database. > > To be able to use an OO database effectively requires that you have > good skills in creating object orient code. Unfortunately there are > not many people who create good object orient code as it takes time to > acquire the skills. Most people just don't have the patience to learn > the skills or have no idea how much more effective they would become > when they master the skills. If they knew what they were missing they > would likely make the effort. > > Anyway, lets say you want to build an OO app that does not have the > need to store data persistently. If you had an object of type Oa that > had a attribute called obs that was a list that contained objects of > type Ob. So you end up having a one to many relationship between Oa > and Ob classes. Would you need a query language when you have a > reference to an Oa object and would like to iterate the Ob objects that > are linked to the obs attribute? I don't think so. Now this is just a > simple example but I hope you start to understand why an OO database > doesn't require a query language. > > Now OO databases are not for all projects. OO databases would be a bad > choice if you have projects that are written in different languages > that need access to the same data. They are also a bad choice when an > application needs to be able to perform complex and ad-hoc searches > over the data. Now don't be fooled by that last statement. Many times > people think they need the flexibility in querying that a relational > database offers but quite often that is not the case. If you end up > creating relational databases with many tables that have many fields > but only find yourself querying on only one or two fields and rarely > need to perform an ad-hoc query, as you already know all the possible > queries you may need, I would say you chose the wrong type of database. > > Hopefully this makes some sense and just maybe a few of you we see the > light and start to recognize when to use an OO database over a > relational one. Using the right tool for the job can make a really big > difference. > > John > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
