PAYATHON 2026

MS Access 连接 VPS 上的 SQL Server，如何设计多租户多数据库架构？

数据阿明

可以保留 MS Access，在 VPS 上用一个 SQL Server 实例承载多个业务数据库。原型阶段先决定 Access 是直接连接 SQL Server，还是通过 API 访问所有业务数据。两种方式对身份验证、权限控制和前端改造工作量的要求不同。

如果现有界面主要依赖链接表和绑定表单，可以先验证 Access → VPN → SQL Server。如果必须通过 Microsoft Entra ID 统一控制每次业务访问，可以采用 Access → HTTPS API → SQL Server，但前端需要做更多开发。不要只用 API 验证一次身份，再把共享数据库密码交给客户端。

先明确 Tenant 和数据库的对应关系

可以按照描述，让一个业务 Tenant 对应一个数据库，由该 Tenant 内的多个客户共同访问：

一个 SQL Server 实例
├── 配置数据库：用户、业务 Tenant、数据库映射
├── 业务数据库 A：Tenant A 的数据
└── 业务数据库 B：Tenant B 的数据

还需要确定同一数据库内的客户能否互相查看数据。

  • 如果这些客户本来就共享数据，数据库可以作为主要的租户隔离边界。
  • 如果客户之间也必须隔离，每个数据库内还需要客户级授权，例如由 API 强制过滤，或通过数据库权限、Row-Level Security 实现。

配置数据库只负责记录映射，不会自动提供隔离。SQL Server 权限和 API 授权仍需分别落实。

多个数据库便于分别备份、恢复和迁移，但它们仍共享同一实例的 CPU、内存和磁盘资源。一个高负载租户可能影响其他数据库；多数据库也不等于高可用。

路径一：保留 Access 链接表，通过 VPN 连接

如果希望尽量沿用 Access 的表单、报表和链接表，可以先验证这条路径：

Access → VPN → SQL Server 私有地址或受限端口

实施时建议：

  1. 每位用户使用自己的 Access 前端副本。
  2. 通过 VPN 身份验证建立网络连接，限制客户端能够访问的服务器和端口。
  3. SQL Server 使用可独立撤销的用户身份，并仅授予所需数据库权限。
  4. 使用 TLS，并正确验证服务器证书。
  5. 用实际 Access 和 ODBC Driver 组合验证登录、重连、查询及编辑操作。

VPN 身份验证与数据库身份验证是两个步骤。连接 VPN 不代表自动获得数据库权限，也不要为方便而给所有客户分发高权限共享 SQL 账号。

动态公网 IP 主要使固定 IP 白名单难以维护，防火墙仍然有用。客户端主动建立 VPN 后，可以按 VPN 网络和访问策略限制 SQL Server 的入口。

如果必须让 SQL Server 直接接受 Microsoft Entra ID 身份，还需要验证服务器版本、相关配置以及 Access/ODBC 客户端的兼容性。API 登录成功，并不意味着 ODBC 会自动获得同样的身份。

路径二：让 API 承担全部业务访问

采用 API 时，建议把数据库连接信息留在服务器上：

Access 获取用于 API 的 access token
    ↓
API 验证 token，并检查用户权限
    ↓
API 查询用户与业务 Tenant 的映射
    ↓
API 使用服务器端配置连接目标数据库
    ↓
返回经过授权的数据

原方案中的“登录后取得 connection string”需要调整。如果连接字符串包含共享凭据，用户拿到后就可以绕过 API；API 中的租户检查、禁用账号和访问规则，也不会自动约束这些直接 SQL 连接。

如果返回的只是数据库地址，随后 SQL Server 仍独立验证每位用户身份，这种设计可以成立，但需要维护两套访问边界，原型阶段通常会增加工作量。

API 至少需要完成以下检查：

  • 验证 token 的签名、签发者、目标 audience 和有效期。
  • 检查所需 scope 或应用角色。
  • 根据服务端保存的关系，确认用户可访问哪个业务 Tenant、哪个客户的数据。
  • 从服务端配置选择数据库，拒绝客户端提交任意连接字符串。

Microsoft Entra ID 中存在某个用户，不等于该用户自动拥有应用权限。Microsoft 文档要求 API 验证 token 和相关授权声明，可参阅 access token 验证说明与声明授权检查。

还要区分 Microsoft Entra tenant 与业务 Tenant：前者是身份目录边界，后者是应用数据边界，两者不一定一一对应。

Access 运行在用户电脑上，不能可靠保守应用级 client_secret。桌面登录可考虑 Authorization Code Flow + PKCE，并通过合适的身份库或辅助组件实现。具体接入方式需要验证，不能直接把桌面应用示例当作可用的 VBA 代码。Microsoft 桌面 OAuth 说明

这条路径的主要代价在 Access 端：普通链接表不能直接变成 HTTP API。通常需要编写请求、解析响应、填充本地数据以及提交修改的逻辑。

Azure Arc 能解决什么

Azure Arc 可以把 VPS 上的 SQL Server 接入 Azure 管理。相关 agent 和 SQL Server 扩展部署在服务器侧；仅为管理这台 SQL Server，不需要把每位客户的电脑都接入 Arc。SQL Server enabled by Azure Arc 概述

需要区分三个概念：

  • VPS 上自行安装的 SQL Server：数据库运行和维护由你负责。
  • SQL Server enabled by Azure Arc：现有 SQL Server 接入 Azure 的管理能力。
  • Azure SQL Managed Instance：另一种服务形态，不能因为安装 Arc 就将现有实例视为该服务。

Arc 不会替代业务 API，也不会自动建立客户到数据库的 VPN，或自动完成租户权限设计。

在符合条件的 SQL Server 部署中，可以通过 Arc 相关配置启用 Microsoft Entra 身份验证，但具体步骤和支持条件取决于 SQL Server 版本及部署环境。应按目标版本核对官方配置教程。

是否引入 Arc，可以根据服务器管理或直接数据库身份验证的需要决定，不必把它作为多租户原型的前置条件。

每小时数万行，应先优化数据访问方式

“每位用户每小时数万行”还不足以判断需要多大的 VPS。实际压力取决于行宽、同时活跃用户数、查询耗时，以及请求是否集中发生。

普通 view 不会因为封装了计算表达式就自动缓存计算结果。应检查执行计划、索引和实际返回列，避免每次打开表单都重新计算并传输完整结果集。

建议先做到：

  1. 查询在 SQL Server 端过滤、聚合，只返回需要的列。
  2. 列表分页，报表按明确范围查询。
  3. 对重复刷新考虑增量获取，并设计好更新和删除数据的同步规则。
  4. 用实际 Access 表单验证网络往返次数和等待时间。

下面是 API 路径中分页查询的示意。表名和字段均为示例，参数必须由数据库驱动绑定：

SELECT TOP (@PageSize)
       OrderId,
       OrderDate,
       TotalAmount
FROM dbo.Orders
WHERE CustomerId = @AuthorizedCustomerId
  AND OrderId > @AfterOrderId
ORDER BY OrderId;

这里假设 OrderId 唯一且可用于稳定排序。@AuthorizedCustomerId 必须由服务端授权结果确定，@PageSize 也应限制范围。如果允许客户端任意指定客户编号，这条查询本身就不能提供客户隔离。

如果采用 Access 直接连接，可以通过 pass-through query 明确让 T-SQL 在 SQL Server 执行。其结果在 Access 中为只读，编辑场景需要另行设计。不要直接粘贴上面的参数化查询，并假设 Access 会自动完成参数绑定。Access pass-through query 说明

不要用“Azure 只有 300 个 session”作为选型依据

Azure 并不存在适用于所有数据库产品和规格的统一“300 个并发 session”限制。Azure SQL Database 的 session 和 worker 限制随服务层级与计算规格变化，而且 session、正在执行的请求和 worker 是不同概念。Azure SQL Database 资源管理说明

成本也需要按相同工作负载比较。VPS 预算除了主机，还应包括适用的系统与 SQL Server 授权、备份存储、流量和维护成本。目前没有用户规模、数据量、部署地区和恢复要求，无法可靠判断 VPS 一定比 Azure 便宜。

原型阶段的落地顺序

先选一个业务 Tenant、一个数据库和一个最常用的 Access 表单，完成查询、编辑、断线重连和恢复演练。

如果保留现有绑定表单是首要目标，先验证 VPN + ODBC，并把数据库权限做完整。如果 Entra ID 统一授权是硬性要求，先验证 Access 获取 token、调用 API、显示数据和提交修改的整条链路，再扩展到其他功能。

无论选择哪条路径，都应从一开始维护用户到业务 Tenant 的映射、统一数据库结构升级，并准备可恢复的备份。等原型暴露出实际瓶颈，再决定是否拆分实例或迁移托管服务。

备注：内容仅供参考。