我试图找出在数据仓库中填充临时数据库的最佳方法。我将拥有许多数据库（相同的架构，SQL Server 2005 Standard）。理想情况下，我会将每个人都设置为出版商，并使用相同的出版物。将有一个订阅者数据库（SQL Server 2005 Enterprise）订阅每个发布者数据库。发布者数据库中的数据将被修改。订阅者数据库将仅由其订阅更新，因此不需要将更改发送回任何发布者。发布者数据库不需要相互更新。复制将通过 Internet 进行（尽管可以使用 VPN）。
我不清楚我应该为此使用哪种复制。我可以通过复制来做到这一点吗？增量字段呢？
复制绝对可以处理这个问题。除了沼泽标准设置之外，您无需执行任何操作，除非不同发布者的表格之间存在任何重叠。也就是说，如果您将 pub_a 和 pub_b 作为发布者，并且都有一个表 tbl_a，那么您要么必须将它们发布到订阅者的不同表（目标表在您对 sp_addarticle 的调用中定义），要么您必须保证不同发布者之间的数据永远不会发生冲突。在后一种情况下，您还需要注意在调用 sp_addarticle 时为 @pre_creation_cmd 参数提供的内容。默认设置是在订阅者处删除表，这意味着添加到组合中的最后一个发布者将获胜，其余的将被破坏。您需要为第一个添加的发布者指定“drop”，为其余的发布者指定“none”。祝你好运！
I believe that this would be possible, but you'd set it up the opposite way around than you've specified. You'd set the central database as the publisher, and you'd use Merge Replication.
Merge Replication includes an option to allow dynamic filters - so what you'd want to do is set the filters up so that each subscriber only receives the rows that it originated - probably by adding a column to some of your tables to include the HOST_NAME() of the server where the row originated. You shouldn't need to do this to every table, because once you've filtered one table, you can have cascading filters that filter out rows from additional tables using joins.
As to "incremental fields" - I assume you're talking here about IDENTITY columns? Luckily, these have also been thought about - basically, the publisher manages the IDENTITY range, and hands out smaller ranges (of 1000 values, by default) to each subscriber.
Caveat - these are the general principles, but I haven't tried this kind of setup myself before. I'd recommend that you try it in a "toy" database first, and try to get it working.