Andreas Kostyrka wrote: > 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. >
Is an OO database out of the box a full fledge database? Unless your application is very basic the answer is no. You will have to write some code to make it into a database. Your skills with OO design will determine how well and useful your OO database will perform. There will be some people who will do this poorly and some will do an outstanding job and will put together a database for a particular application that no relational database could even dream of handling. It's not wrong to have to write some code to complete the database. It is this feature that gives an OO database its power. Maybe you feel it's a waste of time to have to write this code as it's not needed in a relational database. I could take a similar view with a relational database and say writing the scheme as it's not need in an OO database. But without the scheme a relational database is useless. So in one case you write code and other case you write a scheme to perform the equivalent task. I know someone is going to say that it is easier to write the scheme than to write the code. This is true for many applications but not for all of them. I would not use the differences in writing code compared to scheme as your rational for choosing one database type over the other. I would chose the database type based on access and usage patterns, the complexity of the problem or how well the the problem fits into the database type, and whether or not the database type will have acceptable performance for the job. In general I would but business type applications in relational databases and science/engineering applications in OO databases. This is just a stereotype that is usually correct by YMWV. > 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. No problem. Just pass in a reference to the parent when you create the object and have the object store a weak reference to it. Not anymore of an effort than creating a backref in a relational database. >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. > If you need concurrent access in in OO database just write your code to handle it. For some applications you could just add and xml-rpc server to your code. For simple applications this can be accomplish with just a couple lines of code. I realize that concurrent access is built into a relational database but it does come at a cost. Applications that don't need it will run slower than necessary as they have to open and close connections, build query strings just to have the database parse it and the data being passed around have to be converted to and from strings if they aren't already strings. For many applications this overhead is not significant but in others it is. For an application that needs only 1 query every few minutes it won't be a problem but if you have one that needs 10,000 queries per second it will be a show stopper. > 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. > Like I said if you need ad-hoc queries than a OO database is wrong for you application. Now if every now and then you need to access data in your OO database in a way that you didn't think of the just modify the code for your OO database. This is no different than having to change your scheme in a relational database. You are not likely going to get either one of them it right or complete from the beginning. 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 -~----------~----~----~----~------~----~------~--~---
