relational for what? [was: Design Principles Behind Smalltalk, Revisited]

J J azreal1977 at hotmail.com
Wed Jan 3 20:47:26 UTC 2007


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




More information about the Squeak-dev mailing list