Thread: object oriented vs relational DB
Perhaps a mistake to ask this here (heresy I suspect) but I would be interested in the perspectives of people who make a living at this. Background: I am a molecular biologist trying to build a database containing genomic data, strain details, community info (people, publications etc....). Everything except the genomic data is currently housed in an object-oriented acedb database. In conversations with other groups who are going through the same transition we are someone stated that: ".....is perhaps evolving its schema _more_ now that sequencing is finished and annotation is really picking up speed, you should not think that the changes are going to get less ! You will have to deal with problems like genes that get renamed but you still need the old name around, how to cross reference oligos to many parts of sequence, how to organise RNAi data that may end up matching multiple chromosomes etc. etc. I don't want to put you off, but as far as I aware, constantly evolving schema is not one of relational databases strengths." Their solution is to maintain a mixed system of acedb and a relational db: where the working dbs are all acedb and the web site is a mixture of an acedb server and a relational relational db. The data in the mysql database is directly derived from the acedb reference database. Any thoughts? regards, Charles
Charles, > ".....is perhaps evolving its schema _more_ now that sequencing is > finished and annotation is really picking up speed, you should not > think that > the changes are going to get less ! You will have to deal with > problems like > genes that get renamed but you still need the old name around, how to > cross > reference oligos to many parts of sequence, how to organise RNAi data > that may > end up matching multiple chromosomes etc. etc. I don't want to put > you off, but > as far as I aware, constantly evolving schema is not one of > relational databases > strengths." All of the above issues are easily solvable by a SQL expert. "You show me somebody preaching about the 'limitations' of relational databases, and I'll show you somebody with a poor knowledge of the SQL standard, or who is using an inferior SQL RDBMS." > Their solution is to maintain a mixed system of acedb and a > relational > db: where the working dbs are all acedb and the web site is a mixture > of > an acedb server and a relational relational db. The data in the > mysql > database is directly derived from the acedb reference database. > > Any thoughts? Hey, if it works for them. Apparently they have an AceDB expert on staff, but no SQL expert on staff. Greater technology decisions than the above have been made on that basis -- you have to work with the staff you have. Just don't let them justify their *pragmatic* technology decision with a bunch of theoretical BS. Now, for the soapbox. (YMMV): I've looked into OODBMS for my business. However, I've kept from using any in production for one simple reason: lack of a standard.There is no international standard for OODBMS, meaningthat each OODBMS is its own animal and databases are not at all portable between different software packages. Nor is your knowledge of one OODBMS even 20% tranferrable to another. In comparison to relational databases, this is like turning the clock back to 1980, when every database implementation was idiosyncratic and using two database systems in the same enterprise was darn near impossible. While modern programming languages make this easier through middeware than it was then, it's still not a desirable situation. I'll check on the progress of OODBMS in another couple of years. Who knows, ANSI might codify OODB-UML as a standard, and then we'll have something to build on. But until then ... the RDBMS model has been around for 32 years, and the SQL standard for 20, and that a lot of accumulated wisdom to throw away casually. -Josh Berkus
On Thursday 17 Oct 2002 4:03 pm, Josh Berkus wrote: > Charles, > > > as far as I aware, constantly evolving schema is not one of > > relational databases > > strengths." > > All of the above issues are easily solvable by a SQL expert. "You > show me somebody preaching about the 'limitations' of relational > databases, and I'll show you somebody with a poor knowledge of the SQL > standard, or who is using an inferior SQL RDBMS." A "constantly evolving schema" is a limitation of an RDBMS to be fair. What seems to be missed by people who have problems with this is that a constantly evolving schema is a sign of design problems too. The schema is supposed to represent the *meaning* of your data - if the schema is evolving your analysis was incorrect at the start. How would you feel about a library with "constantly evolving categories" for filing its books? Anyway Charles, I agree with Josh's comments and just thought I'd point you at the following site that has plenty of discussion on relational vs object - oriented database systems. http://www.dbdebunk.com/ -- Richard Huxton
Josh Berkus schrieb: >I've looked into OODBMS for my business. However, I've kept from >using any in production for one simple reason: lack of a standard. > There is no international standard for OODBMS, meaning that each >OODBMS is its own animal and databases are not at all portable between >different software packages. Nor is your knowledge of one OODBMS even >20% tranferrable to another. > > Same here. I've done a project with Versant five years ago and we were badly hit by the decision of the database vendor to give up a special language binding - just as we had finished the project. For that reason I would never ever do a project again with oodbms - no standard, no way of switching the database product. The problem is, that the ODMG group is so much influenced now by the Java hype, that nobody seems to expect, that the ODMG 3.0 standard seems to be a real thing. Another view about comp.databases.objects shows us, that the Java world produces one new oodbms each week and they do not care about any standards. Their standard is Java and the rest of the world is meaningless. >In comparison to relational databases, this is like turning the clock >back to 1980, when every database implementation was idiosyncratic and > >I > Well, well spoken and still unbelievable ! :-)