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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070102/0b5b6649/attachment.htm