Based on the thoughtful responses I've gottten, I'll be taking a new  
look at some oodb technologies - but I'm pretty sure I've made the  
right move for my current project. Honestly, working with glorp is no  
more or less complex than working with an oodb - they feel about the  
same to me - especially since I derive the schema from the meta model  
anyhow.

On Jan 3, 2007, at 12:47 PM, J J wrote:

> A big +1 to most of this message (just not the anti-OODB stuff.   
> They have not had any poison for me yet)
>
>
>> From: Todd Blanchard <tblanchard at mac.com>
>> Reply-To: The general-purpose Squeak developers list<squeak- 
>> dev at lists.squeakfoundation.org>
>> To: The general-purpose Squeak developers list<squeak- 
>> dev at lists.squeakfoundation.org>
>> Subject: Re: relational for what? [was: Design Principles Behind  
>> Smalltalk,Revisited]
>> Date: Tue, 2 Jan 2007 17:28:25 -0800
>>
>>
>> On Jan 2, 2007, at 1:36 PM, goran at krampe.se wrote:
>>
>>> Using the RDB as a sharing ground for applications is IMHO really,
>>> really bad. Sure, it *works* kinda, but very fast you end up with
>>> replicated SQL statements all over the place. Then someone says   
>>> "stored
>>> procedures" and hey... why not consider OBJECTS? There is probably a
>>> reason why people are so worked up about Services these days. :)
>>
>> So if it is objects instead of tables - how is this different?
>> Uh, and the alternative would be what?  Take a typical company  
>> that  makes and sells stuff.
>>
>> They have customers (hopefully).
>>
>> The marketing guys want the customer's demographics and contacts  
>> to  generate targeted messages.
>> The accounting people what to know their credit status, payments,  
>> and  order totals.
>> The inventory/production planning guys don't really care who is   
>> buying what, but they want to see how much of each thing is going  
>> out  the door.
>> The product development people are looking for trends to spot new   
>> kinds of demand trends.
>> The sales guys want recent order history, contact event logs, etc.
>>
>> There are many cross cutting concerns.
>>
>> If you take the naive object model you probably have
>> Customers->>Accounts->>Orders->>Items-----(CatalogItem)- 
>> >InventoryStatus
>>
>> Works for most traversals, you put the customers in a dictionary  
>> at  the root by some identifier.
>> But for the people who process orders or do shipping, this model  
>> is a  drag.  They just want orders, and items and navigating to  
>> all the  orders by searching starting at customers is nuts.  So  
>> maybe you add  a second root for orders for them.  Then there's  
>> the inventory stuff....
>>
>> Everybody wants a different view with different entry points.   
>> I'm  talking enterprise architecture here - bigger than systems  
>> which is  bigger than applications.
>>
>> Relational databases  don't care about your relationships or roots  
>> -  anything can be a root.  Anything can be correlated.  Any  
>> number of  object models can map to a well normalized.
>>
>> RDBMS systems have a couple nice properties - you can produce lots  
>> of  different views tailored to a viewpoint/area of  
>> responsibility.  They  guarantee data consistency in integrity.   
>> Something I find lacking  from OO solutions.
>>
>> Here's a fun game.  Build an OO db.  Get a lot of data.   
>> Overtime,  deprecate one class and start using another in its  
>> place.  Give it to  another developer who doesn't know the entire  
>> history.  One day he  deletes a class because it appears not to be  
>> referenced in the image  anymore.  6 months later try to traverse  
>> the entire db to build a  report and find errors 'no such class  
>> for record'.  What will you do?
>>
>> This has happened BTW to me. If I have long lived data, with   
>> different classes of users and different areas of  
>> responsibilities, I  want the RDBMS because it is maximally  
>> flexible while providing the  highest guarantees of data integrity  
>> and consistency.  The problems  I've heard described are the  
>> result of poor design and unwillingness  to refactor as the  
>> business changes and grows.
>>
>> FWIW I have worked at everything from 5 person Mac software  
>> companies  (anyone remember Tempo II?) to telcos, aerospace,  
>> government  agencies, and the world's largest internet retailer (a  
>> scenario where  the relational database turns out to be not the  
>> best fit overall).   My solution selection hierarchy as the amount  
>> of data grows runs:
>>
>> 1) In the image
>> 2) Image segments or PLists in directories
>> 3) RDBMS/ORM like glorp
>> 4) RDBMS with optimized SQL
>> 5) SOA
>>
>> I'm pretty sour on OODBMS's based on my long running experiences  
>> with  them.
>>
>> -Todd Blanchard
>
>
>>
>
> _________________________________________________________________
> Get live scores and news about your team: Add the Live.com Football  
> Page www.live.com/?addtemplate=football&icid=T001MSN30A0701
>
>