小编8kb*_*8kb的帖子

当我为存储过程编写单元测试时，它们通常如下所示：

/* Unit test for stored procedure which runs a query */

/* Define #temp table with structure of query results */

/* Define and set variables for stored procedure parameters */ 

/* If stored procedure queries from a particular table...*/ 

/* Truncate table and populate with sample data */ 

/* Call stored procedure using variables but insert results into table */ 

/* INSERT #temp EXEC usp_TestProc @P1=1, @P2 = 'X' */

/* Query #temp table to confirm that all …

我有一个接受各种 varchar 参数的存储过程。调用该过程的中间层代码在它提交的值方面不一致。例如，有时像“传输描述”这样的参数会被提交为 NULL，有时它会是一个空字符串。

就客户端而言，空字符串仅表示未输入值。

在插入数据之前，我应该将所有空的 varchar 参数转换为 NULL 吗？

我无法确定这是否属于保持数据完整性的最佳实践，还是一个坏主意，因为我没有代表实际提交给数据库的内容。

我应该注意到所有插入和更新都在审计日志中进行跟踪。

假设我有两个经常针对我的数据库运行的查询：

SELECT 
  UserID,
  UserName,
  UserGender
FROM Users
WHERE UserID = @User

SELECT 
  UserID,
  UserName,
  UserGender
FROM Users
WHERE UserName LIKE @Name + '%

它们应该在两个单独的存储过程中，还是只是一个使用 sp_executesql 动态创建语句的存储过程？

如果它们在两个存储过程中，那么如果我想在 SELECT 语句中添加或删除列，我将需要修改这两个过程。如果我使用动态 SQL，那么大概我会牺牲少量的性能。

在这种情况下，使用动态 SQL 的可维护性和遵守 DRY 原则（不要重复自己）会优先于存储过程的性能增益吗？

过去，我的团队有一个政策，任何存储过程修改都需要在两个地方进行注释：

1. 存储过程的顶部以及所做更改的总体摘要
2. 对进行更改的每一行的注释

它通常看起来像这样：

CREATE PROCEDURE usp_Test
/*****************************************************************
The purpose of this stored procedure is to get data.
Created by 8kb 2001-01-01
Modified: removed OR clauses from JOIN statement..8kb 2001-06-01
******************************************************************/
AS
BEGIN

SELECT * 
FROM t1
JOIN t2
ON t1.colA = t2.colA
-- Removed OR clause..8kb 2001-06-01
-- OR t1.ColB = t2.ColB

END

但是现在有了集成的源代码管理，我可以总结源代码管理中的变化，然后使用比较/差异功能来查看新旧版本之间的差异。

在作为集成源代码控制一部分的存储过程中编写逐行更改注释是否仍然有价值？

每天将大约 200 个 SQL Server 2005 源数据库（相同架构）加载到暂存区以准备数据仓库清理、重复数据删除和转换的最佳提取策略是什么？

到目前为止，我已经设想了以下可能性：

1. 事务复制：创建 200 个 SQL Server 2008 R2 订阅者，在 2005 年从各自的发布者那里提取数据。在订阅者和影子表中的所需表上启用变更数据捕获，以便对我们的临时数据库执行增量加载。
2. Rowversion：在每个所需的源表上添加一个 rowversion 列，并将其与 SSIS 过程结合使用以将更改数据直接提取到临时数据库。
3. BCP 文件：创建一个自动化任务，每晚从所有源表中转储 BCP 文件。使用 SSIS 将这些表作为完整加载（而不是增量加载）的一部分加载到临时数据库中。

额外的想法：

1. 我对在 200 个数据库上支持全新事务复制拓扑所需的管理和硬件开销感到紧张。
2. 数据库的总大小约为 100GB。但其中大部分是事务日志和其他表的一部分，不会在任何事实或维度中使用。换句话说，BCP 文件不会很大，这就是为什么我正在考虑完整的提取策略，即使我读过的所有内容都反对它。
3. 我愿意接受建议、文件等。