> How about instead of issuing SQL and routing the query based
> on parsing that
> SQL, you add a service layer that can execute queries for
> yuor domain layer.
> That service layer can obtain a connection from the required
> DB based on the
> arguments to the service call.
<good fun>
For a break in the Moron need's a developer comedy
:>>
No actually, the folks in Atlanta (I live here too) at eHatchery are
good people working on a dotcom incubator business model and tool kit.
I'm most thankful for all the fun we've had today with this!!!!!
Thanks guys!! Especially that reply instead of forward escapade.
:-P
</fun has ended>
<tech issue>
I'm a bit surprised that that no one's heard of a persistance layer
[Top link, coco base, power tier] that can do some portion of
this problem?
I thought the old data warehousing, decission support problems where
solved with schema aggregator / caching layers??
e.g. commercial products by someone?
But Chris's notion of a DbServiceProvider layer is a way to roll my
own.. Also the FileCabinet Facade is another concept.
</tech issue>
Thanks
curt
>
> -Chris.
>
> > -----Original Message-----
> > From: Smith, Curt H. [SMTP:[EMAIL PROTECTED]]
> > Sent: Friday, July 07, 2000 9:00 AM
> > To: [EMAIL PROTECTED]
> > Subject: Persistence layer: vertical DB segmentation,
> many DB's
> >
> > Hi,
> >
> > I'm trying to solve an interesting problem in my
> persistance layer, DB
> > connection
> > pooling.
> >
> > Issue:
> >
> > - We have many physical DB's, segmented by city. Same
> schema at each
> > location.
> >
> > - An SQL statement: select row, row from customer where
> cust_id='some
> > location's customer';
> >
> > How can this SQL be routed to the correct DB connection
> (physical DB)
> > based on:
> >
> > - table
> > - value of the select by columns and values
> > (horizontal table segmentation)
> >
> > - I don't want my business logic to worry about grabbing
> the correct DB
> > connection based on
> > range of primary keys, table names etc etc!!!!
> >
> > Possible solution:
> >
> > - This is an age old decission support big DB problem that various
> > persistence layer
> > products and tools have been developed to solve
> >
> > - The data warehousing problem also looks like what our
> segmented physical
> > DB arch. would
> > look like.
> >
> > - Find a persistance layer that works with Appserver ABC
> that does table
> > and
> > key ranges routing
> > to the correct physical DB.
> >
> > - All DB connections in the Appserver's pool are equal and will work
> > regardless of the table,
> > primary key value, etc you are accessing.
> >
> > Anyone have comment or products that may help with this?
> >
> > Thanks.
> >
> > curt
> >
> > Curt Smith
> > Z-Tel, Architect
> > email: [EMAIL PROTECTED]
> > work: 404-237-1166 x182
> > FAX: 404-237-1167
> >
> >
> ==============================================================
> ============
> > =
> > To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the
> > body
> > of the message "signoff EJB-INTEREST". For general help,
> send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
>
> ==============================================================
> =============
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> of the message "signoff EJB-INTEREST". For general help,
> send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
