Re: Multiple databases or not
From: Bonj (benjtaylor)
Date: 10/21/04
- Next message: Louis Davidson: "Re: Table design help needed"
- Previous message: Joe Palm: "Speeding up DTS package creation?"
- In reply to: Ryan Johnson: "Multiple databases or not"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 21 Oct 2004 21:57:18 +0100
Be sure to split it into layers - for example, have one 'layer' where the
suppliers can have different codes, and one where they are, for example,
translated into a standard format or given your own ID (if that's what you
are planning to do). The difference being that one layer's specific, while
the next is generic and combines them. Making each and every layer big
enough to contain business logic if need be is important.
The 'layers', can ideally be, views.
For instance, one of our systems has two layers of views, one set that
combines values from all tables and converts all values to an acceptable
format to perform calculations on, and another that returns the columns in
the correct order for the report and performs any formulas and does derived
columns, etc. Trying to implement all that logic in just one SP would be a
nightmare - trying to do too many things at once. But as two separate
layers, it works a dream.
"Ryan Johnson" <RyanJohnson@discussions.microsoft.com> wrote in message
news:A1C32A94-06F7-4E62-92C0-BC695B84F76C@microsoft.com...
> Hi there
> We're rewritting and redesigned our core database but have a slieght
> delima
> with whats the best practice with regard to importing / utilising external
> data.
> Basically we use external product list from our suppliers which is
> automated
> into our existing database.
> say tbl_MSDProductList1 as we buy this from MSD supplier.
> (the product list tables have around 400,000 records)
>
> Now with the new design, we are looking at using completely different
> product list from a different supplier in america - depending on the
> client.
> This might grow as we expand into different countries.
>
> So, should we have this imported data in another database for each
> supplier(Supplier1.dbo.tblProdList1, Supplier2.dbo.tblProdList2 etc), or
> somehow have them incorporated as part of our application via a view.
> To complicate things.. the suppliers use different codes and have
> different
> field names.
>
> What I was thinking was all the core application in one database and this
> uses a view to access the external databases dependant on the client.
> thereby abstracting the productlist from the core application and enabling
> us
> to swop and change suppliers.
>
> i.e. one view pulls in productlist 1
> i.e. one view pulls in productlist 2
>
> a generic view which concatinates them then using this clientID this pulls
> the correct product lists depending on client.
>
> Any one done this or have any ideas or best practices?
- Next message: Louis Davidson: "Re: Table design help needed"
- Previous message: Joe Palm: "Speeding up DTS package creation?"
- In reply to: Ryan Johnson: "Multiple databases or not"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
