我太懂这种重复劳动的痛苦了——50个存储过程每次新增地点都要复制粘贴微调代码，不仅容易手抖写错，长期维护下来简直是噩梦。给你几个从简单到进阶的方案，彻底解决这个问题：

方案1：动态SQL + 中央配置表（最灵活，推荐） #

核心思路是把所有地点的数据源信息存在一个配置表里，存储过程根据传入的@LOCATION参数动态读取配置，拼接SQL执行。这样新增地点只需要往配置表里加一行，完全不用碰那50个存储过程。

第一步：创建地点配置表 #

先建一个统一管理数据源的表，把每个地点对应的服务器、数据库、表名都存进去：

CREATE TABLE LocationDataSources (
    LocationCode VARCHAR(50) PRIMARY KEY, -- 比如'Canada'、'USA'
    ServerName VARCHAR(100),              -- 数据源服务器名
    DatabaseName VARCHAR(100),            -- 数据库名
    SchemaName VARCHAR(50) DEFAULT 'dbo', -- 架构名，默认dbo
    TableName VARCHAR(100)                -- 目标表名
);

-- 插入现有地点的配置
INSERT INTO LocationDataSources VALUES
('Canada', 'SERVER20', 'Shop_Canada', 'dbo', 'report_asset_history'),
('USA', 'SERVER20', 'Shop_USA', 'dbo', 'report_asset_history');

第二步：重构存储过程 #

把原来的IF判断换成动态SQL，从配置表取数据源信息：

CREATE PROCEDURE GetAssetHistoryByLocation
    @LOCATION VARCHAR(50)
AS
BEGIN
    SET NOCOUNT ON;

    -- 先校验传入的地点是否合法，避免无效参数
    IF NOT EXISTS (SELECT 1 FROM LocationDataSources WHERE LocationCode = @LOCATION)
    BEGIN
        RAISERROR('无效的地点编码: %s', 16, 1, @LOCATION);
        RETURN;
    END

    -- 从配置表获取当前地点的数据源信息
    DECLARE @ServerName VARCHAR(100), @DatabaseName VARCHAR(100), 
            @SchemaName VARCHAR(50), @TableName VARCHAR(100);
    SELECT @ServerName = ServerName, @DatabaseName = DatabaseName,
           @SchemaName = SchemaName, @TableName = TableName
    FROM LocationDataSources WHERE LocationCode = @LOCATION;

    -- 拼接动态SQL，用QUOTENAME避免SQL注入风险
    DECLARE @Sql NVARCHAR(MAX);
    SET @Sql = N'
        SELECT location_id, location_description 
        INTO #tempAssetHistory' + QUOTENAME(@LOCATION) + N'
        FROM ' + QUOTENAME(@ServerName) + N'.' + QUOTENAME(@DatabaseName) + N'.' + 
              QUOTENAME(@SchemaName) + N'.' + QUOTENAME(@TableName);

    -- 执行动态SQL
    EXEC sp_executesql @Sql;

    -- 这里可以继续处理临时表的业务逻辑，比如返回数据或后续操作
    SELECT * FROM #tempAssetHistory' + QUOTENAME(@LOCATION);
END

优势：后续新增地点只需要往LocationDataSources插一行数据，所有采用这种模式的存储过程都自动支持新地点，完全不用改代码。而且配置表可以统一管理所有数据源，排查问题也方便。

方案2：使用同义词（Synonym）统一入口 #

如果所有地点的表结构完全一致，可以给每个地点的远程表创建同义词，存储过程通过同义词访问数据。新增地点时只需要创建对应的同义词，不用修改存储过程代码。

第一步：创建同义词 #

给每个地点的目标表创建同义词：

-- 加拿大地点的同义词
CREATE SYNONYM report_asset_history_Canada 
FOR [SERVER20].[Shop_Canada].[dbo].[report_asset_history];

-- 美国地点的同义词
CREATE SYNONYM report_asset_history_USA 
FOR [SERVER20].[Shop_USA].[dbo].[report_asset_history];

第二步：修改存储过程 #

通过动态SQL调用对应同义词：

CREATE PROCEDURE GetAssetHistoryByLocation
    @LOCATION VARCHAR(50)
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @SynonymName VARCHAR(100) = 'report_asset_history_' + @LOCATION;

    -- 校验同义词是否存在
    IF NOT EXISTS (SELECT 1 FROM sys.synonyms WHERE name = @SynonymName)
    BEGIN
        RAISERROR('未找到对应地点的同义词: %s', 16, 1, @LOCATION);
        RETURN;
    END

    -- 拼接并执行动态SQL
    DECLARE @Sql NVARCHAR(MAX);
    SET @Sql = N'
        SELECT location_id, location_description 
        INTO #tempAssetHistory' + QUOTENAME(@LOCATION) + N'
        FROM ' + QUOTENAME(@SynonymName);

    EXEC sp_executesql @Sql;

    -- 后续业务逻辑
    SELECT * FROM #tempAssetHistory' + QUOTENAME(@LOCATION);
END

优势：实现简单，不需要维护配置表，新增地点只需要执行CREATE SYNONYM语句即可。适合表结构稳定、数据源变动少的场景。

方案3：重构通用逻辑为核心存储过程 #

如果那50个存储过程的业务逻辑大部分重复，只是数据源不同，可以把通用的数据源访问逻辑抽成一个核心存储过程，其他存储过程都调用这个核心过程。这样后续不管是新增地点还是修改逻辑，只需要维护核心存储过程即可。

比如核心过程就是方案1里的GetAssetHistoryByLocation，其他业务存储过程可以这样调用：

CREATE PROCEDURE ProcessAssetReport
    @LOCATION VARCHAR(50)
AS
BEGIN
    SET NOCOUNT ON;

    -- 调用核心存储过程获取数据
    EXEC GetAssetHistoryByLocation @LOCATION = @LOCATION;

    -- 这里处理当前存储过程的专属业务逻辑
    -- ...
END

注意事项：

1. SQL注入风险：动态SQL一定要用QUOTENAME包裹对象名，或者用sp_executesql的参数化功能，绝对不能直接拼接用户输入的字符串。
2. 权限问题：执行动态SQL的账号需要具备对应远程服务器、数据库的访问权限，如果权限不足，需要提前配置好。
3. 临时表作用域：动态SQL里创建的本地临时表（#开头）只能在动态SQL内部访问，如果需要在外部使用，建议改用表变量或者全局临时表（##开头）。

内容的提问来源于stack exchange，提问作者Benny