我应该对链接SQL Server有什么大的限制？

我们的产品基于Microsoft SQL Server。当前，我们正在使用三个数据库，并且始终将它们部署在一个SQL Server实例上。

这三个数据库是OLTP，OLAP和审计。OLAP数据库使用跨数据库查询，具有来自OLTP和审计的有关EOD的大量入站数据。

问题

如果我们要将这三个数据库部署到单个物理服务器内的三个单独的Standard Edition 实例上，并使用SQL Server的链接服务器功能将它们绑定在一起：

1. 对应用程序代码的透明度如何？我应该期待多少变化？
2. 到OLAP的入站数据总计为5万至10万行，每个EOD负载为200-500MB。我应该期望多少性能下降？
3. 我还应该期待其他哪些重大限制？

背景

目前，我们正在为潜在的第一个客户提供500多个并发用户。

我们正在起草服务器规范，其中包括64个内核和256GB RAM。为了使SQL Server能够利用所有这些丰富的资源，客户端必须购买Enterprise Edition，而对于SQL Server 2016，Enterprise Edition仅在基于每核的许可中可用。

我们担心光是许可成本（64 x 7400美元）就会使他们失望。因此，我正在考虑将数据库分为Standard Edition的三个实例，并将它们链接在一起，希望链接功能对应用程序代码是透明的。

对应用程序代码的透明度如何？我应该期待多少变化？

根本不透明。期待重大变化。

您应该为非常严重的性能下降做好准备。

无论另一端的服务器是哪一个，分布式查询（链接服务器的框架）都使用通用的OLEDB模型。确实，SQL Server目标可能能够提供更完整的信息（元数据，统计信息等），但结果仍然远不及本地跨数据库操作那么紧密地集成或具有。

远程查询因性能低下以及优化器对计划的选择不当而应有的声誉。由于基本模型通常是游标的模型，因此更改数据（删除，插入，更新，合并）的语句特别容易出现。

如果你从来没有需要执行即席跨实例查询，您可能能够手调可接受性能的每个存储的查询，但是这是一个大量的工作，并成功绝不是一种保障手段。

对于跨例如批量操作，你会关闭使用真实批量操作好得多（bcp，BULK INSERT，SSIS ...等）比使用链接的服务器实例之间。

综上所述，基本想法似乎比我认为的要麻烦得多。指定将在标准版的限制内运行的硬件；或者，如果客户端需要更高的性能，则可以使用更大的服务器并使用企业版。