data update suggestions

We have production database (1TB, sql server 2005) and we will receive daily
updates from a vendor. All the updates will be imported in another database
first (source db). What would be the best way to apply the updated
information to the from the source DB to the production DB (example of
updates are: new products or just price changes on existing products
etc...). I was thinking about unidirectional merge database (src db to prod
db) but if someone can give some suggestions it would be greatly appreciated!
Thank you all
--
System Engineer
MSc in CS, MCSE4, IBM Certified MQ 5.3 Administrator
"I saw it work in a cartoon once so I am pretty sure I can do it."
I guess you should start with estimating amount of data being transfered, it
frequency and concurrency requirement.
the more data and more frequent and how fast you have to be "in sync"-
replication is most likely scenario you should go with. Less data and less
frequent - a custom app or SSIS package might do the trick...
"Sas" <Sas@.discussions.microsoft.com> wrote in message
news:0F14BBEA-A720-40FF-88A3-8C7B126DBC46@.microsoft.com...
> We have production database (1TB, sql server 2005) and we will receive
> daily
> updates from a vendor. All the updates will be imported in another
> database
> first (source db). What would be the best way to apply the updated
> information to the from the source DB to the production DB (example of
> updates are: new products or just price changes on existing products
> etc...). I was thinking about unidirectional merge database (src db to
> prod
> db) but if someone can give some suggestions it would be greatly
> appreciated!
> Thank you all
> --
> --
> System Engineer
> MSc in CS, MCSE4, IBM Certified MQ 5.3 Administrator
> "I saw it work in a cartoon once so I am pretty sure I can do it."
|||Why are you using merge when the data flow is in one direction. You should
be using transactional for this. Expect at least twice the amount of data
flow that hits the publisher to be applied on the subscriber. However this
can vary widely depending on how many rows are affected by each DML on the
publisher and whether text or binary data is involved.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Rafael Lenartowicz" <rafaell@.rcl-consulting.com> wrote in message
news:OrX0acKfHHA.1252@.TK2MSFTNGP04.phx.gbl...
>I guess you should start with estimating amount of data being transfered,
>it frequency and concurrency requirement.
> the more data and more frequent and how fast you have to be "in sync"-
> replication is most likely scenario you should go with. Less data and less
> frequent - a custom app or SSIS package might do the trick...
> "Sas" <Sas@.discussions.microsoft.com> wrote in message
> news:0F14BBEA-A720-40FF-88A3-8C7B126DBC46@.microsoft.com...
>
|||How are the updates imported into the source db? If they are indeed applied
as TSQL updates (as opposed to tables being overwritten) then look at
transactional replication. If the schema of the source db and production db
are the same and you have PKs on all the involved tables then things will be
straightforward.
Paul Ibison