SQL Server 2008 复制与手动数据库更新

发布于 2024-08-10 19:11:29 字数 324 浏览 2 评论 0原文

我们的场景:

我们有一个存储公司范围信息的主数据库。我们有几个零售点,它们都有自己的数据库。这些位置需要使用公司范围数据库中的信息,并且我不希望我们的主应用程序运行跨数据库查询,因为如果主数据库出现问题(锁定或其他问题),我不希望它导致应用程序停止发挥作用。

话虽这么说,我们正在考虑两件事:

  1. 复制数据
  2. 运行自动脚本来更新我们自己的每个数据库中的表

我倾向于复制,但我必须承认,我以前从未这样做过(我们不过,确实复制数据,我只是还没有处理它)。有人告诉我,对于大型表来说,复制可能会非常密集。对此有什么想法、建议或好的文章吗?

Our scenario:

We have a main database that stores company-wide information. We have several retail locations which have their own databases they work off of. These locations need to use information in the company-wide database, and I do not want our main application to run cross database queries because if the main database has issues (locks or otherwise), I do not want it to cause the application to cease to function.

That being said, we're considering 2 things:

  1. Replicate the data
  2. Run an automated script to update the tables in each database on our own

I'm leaning towards replication, but I have to admit, I've never done it before (we do replicate data though, I just haven't handled it). I've been told that replication can be pretty intensive for large tables. Any thoughts, suggestions, or good articles about this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

魔法少女 2024-08-17 19:11:29

通常最好使用标准工具来做某事,而不是构建自己的代码。

在这种情况下,最好是降低成本并减少出错的机会。

SQL 复制正是为了完成这项工作而构建的,因此我建议您使用它。

It is generally best to use a standard tool to do something than building your own code.

Best in this case being less cost and less chance of errors.

SQL Replication is built to do exactly this job, so I would recommend that you use it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文