Christian Catchpole wrote: > i didn't say *I* agreed with it. :) > > i wonder if you can mix OO and relational concepts into a DB that > supports both? > Yes, you can. When they started implementing relational databases in the 70s they took a few things away from Codd's ideas (i.e. proper relational algebra). One of those things are the domains. In an RDBMS all you have is tables, while in relational algebra the first thing you have are domains: sets of things. Relational Algebra does not care what these things are (always remember: it is mathematics, so abstraction is king).
Anything in a domain is considered atomic for the purposes of the algebra, but it can have as much structure as you want for other purposes. The only thing you need is a good notion of identity (otherwise you won't get set semantics). If you take this abstract view, nothing stops you from using OO classes as your domains. You can have everything you know from OO in there: encapsulation, inheritance, polymorphism -- for the purposes of Relational Algebra it doesn't matter. Relations are then a different beast. Instead of using object navigation you then model connections between objects by putting tuples into a relation. That can be much nicer for features that are not really intrinsic to an object, need to be navigated both ways or are of higher arity than 2. As an example for the latter: if you want to model who watched which movie in which cinema you can easily create a relation (Person, Movie, Cinema). In Relational Algebra that is a standard step and thus easy, in OO world you would probably end up doing the same with much more pain. Databases which do this mix of objects and relations are called "object-relational". I believe PostgreSQL has some features like that, although I am not sure about that (and writing mail offline, so I can't check). I tried to model this idea in Java, but I never really finished it. IIRC I got as far as implementing a standard Relational Algebra as an in-memory database, but I never got to the mapping into the SQL world, which would be the point where it gets interesting. The basic idea for this tool (http://www.beandb.org) was to model the objects as interfaces and then ask a database to create matching domain objects for those (using dynamic proxies), which could then be combined into relations. The relation objects have the operations of the algebra as methods, so you can call rel1.join(rel2) to get a natural join (in this case matching all values in domains of the same class). It's one of those projects I keep wanting to go back to. Or to redo it in Scala -- something like this doesn't jell too well with Java. > the other thing is, row based databases require each field to have > their max length defined. The total spaced used is the sum of the > size of all the columns. With lots of Strings this can be wasteful, > but i guess it's the whole bases of indexes. rowOffset = index * > rowWidth; > Again I miss the option to look things up, but it is my understanding that a VARCHAR is a VARchar since it is of variable length. A VARCHAR[50] is at most 50 characters, a CHAR[50] is exactly 50 characters. Limiting the maximum amount still allows for a lot of optimizations and can help in case of errors -- just think of it as data validation ;-) > does anyone know if OODBs take the same approach or are they free > form? > I would be surprised if they offer the fixed length form. It seems uncommon outside the COBOL world :-) Peter > On May 15, 2:28 pm, Michael Neale <[email protected]> wrote: > >> I agree with that - except for the bit about most enterprise data >> suiting a relational model - I think its quite the opposite but years >> of DBA brainwashing has convinced everyone otherwise. Very few uses of >> RDBMS I have seen really make much use of the R bit to good effect (at >> best its just a data quality thing). >> >> On May 15, 11:52 am, Christian Catchpole <[email protected]> >> wrote: >> >> >>> I think there are heaps of reasons including the ones you mention. >>> But I think the main thing is that dev's might like the idea of a >>> clean object DB, but in practice, the data held by an organization >>> does not (or should not) match the objects used by a program. And >>> this data shouldn't be tied to any one app. And relational people >>> will argue that most enterprise data suits a relational model more >>> than an OO one. >>> >>> Then there is the whole investment in DB technologies, admin, tuning, >>> reporting, backup, replication etc. >>> >>> I don't know much about OO databases so I can't say how they compare. >>> >>> On May 15, 6:12 am, Nico <[email protected]> wrote: >>> >>>> I'd like to hear the posse discuss why technologies such >>>> ashttp://www.db4o.com/ >>>> has not yet taken over from the traditional Relational Databases like >>>> Oralce, SQL Server, MySQL.. >>>> >>>> Is it because the technology is not mature enough or is it because of >>>> vested interest both political and monetary in large enterprises? >>>> > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" 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/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
