Craig's questions

在事实表或事务表上选择聚集索引的好策略是什么？我正在使用 SQL Server 2019。

我选择了一个具有以下属性的通用销售表 (FactSales)：

1. 没有身份代理键
2. 包含 4 个字段的复合主键（均为 INT）
3. 约 3 亿行
4. 它在每个支票关闭时连续加载，因此每次加载将针对单个 DateOfSaleKey、StoreKey、CheckNumber（并包含许多 SaleItemKey）

我可以看到 5 个选项（但可能还有更多），我在下面编写了这些选项——各有利弊。

请让我知道您会选择什么。以及为什么。

CREATE TABLE dbo.FactSales
(
DateOfSaleKey INT NOT NULL,
StoreKey INT NOT NULL,
CheckNumber INT NOT NULL, -- not unique across stores
SaleItemKey INT NOT NULL,
CashierKey INT NOT NULL,
TerminalKey INT NOT NULL,
SaleTypeKey INT NOT NULL,
TimeSlotKey INT NOT NULL,
TransactionTypeKey INT NOT NULL,
SaleTime DATETIME NOT NULL,
SalesQuantity INT NOT NULL,
SalesNet DECIMAL (16, 8) NOT NULL,
SalesGross DECIMAL (16, 8) NULL,
VAT DECIMAL (16, 8) NOT NULL,
DiscountQuantity INT NOT NULL,
Discount DECIMAL (16, 8) NOT NULL,
VoidQuantity INT NOT NULL,
Void DECIMAL (16, 8) NOT NULL,
RefundQuantity INT NOT NULL,
Refund DECIMAL (16, 8) NOT NULL,
)
ALTER TABLE dbo.FactSales ADD CONSTRAINT PK_FactSales PRIMARY KEY NONCLUSTERED (DateOfSaleKey, StoreKey, CheckNumber, SaleItemKey)

-- OPTION #1: add a surrogate key (identity) and make that the clustered index
-- unique, narrow and always increasing, but unnecessary column
ALTER TABLE dbo.FactSales ADD SalesKey INT IDENTITY NOT NULL
CREATE UNIQUE CLUSTERED INDEX CX_FactSales ON dbo.FactSales (SalesKey)

-- OPTION #2: make the primary key also the clustered index: 
-- unique, but wide
ALTER TABLE dbo.FactSales ADD DROP CONSTRAINT PK_FactSales 
ALTER TABLE dbo.FactSales ADD CONSTRAINT PK_FactSales PRIMARY KEY CLUSTERED (DateOfSaleKey, StoreKey, CheckNumber, SaleItemKey)

-- OPTION #3: base the clustered index on how the data is inserted
-- optimised for inserting new data, but not unique
CREATE CLUSTERED INDEX CX_FactSales ON dbo.FactSales (DateOfSaleKey, StoreKey)

-- OPTION #4: base the clustered index on how the data is selected
-- optimised for inserting new data and some reports, but not unique and getting wider
CREATE CLUSTERED INDEX CX_FactSales ON dbo.FactSales (DateOfSaleKey, StoreKey, SaleItemKey)

-- OPTION #5: base the clustered index on how the data is selected -- more selective (so it covers more reports)
-- optimised for inserting new data and more reports, but not unique and even wider
CREATE CLUSTERED INDEX CX_FactSales ON dbo.FactSales (DateOfSaleKey, StoreKey, SaleItemKey, CheckNumber)

当您需要循环一组数据时，使用 SQL Server 游标有好处吗？或者使用 WHILE 循环（见下文）也一样。

我问这个问题是因为 WHILE 循环看起来更清晰、更容易理解。

-- loop through a table
DROP TABLE IF EXISTS #LoopingSet;
CREATE TABLE #LoopingSet (RowID INT IDENTITY(1,1), DatabaseName sysname);
INSERT INTO #LoopingSet (DatabaseName) SELECT [name] FROM sys.databases WHERE database_id > 4 ORDER BY name;

DECLARE @i INT = (SELECT MIN(RowID) FROM #LoopingSet);
DECLARE @n INT = (SELECT MAX(RowID) FROM #LoopingSet);
DECLARE @DatabaseName sysname = '';

WHILE (@i <= @n)
BEGIN
    SELECT @DatabaseName = DatabaseName FROM #LoopingSet WHERE RowID = @i;
    PRINT @DatabaseName; -- do something here
    SELECT @i = MIN(RowID) FROM #LoopingSet WHERE RowID > @i;
END;

首先，使用代理标识列 (SaleItemID) 作为聚集索引是否更好？或者查找我期望在从表中读取数据时经常使用的列，但它不是唯一的 (SalesCategoryID)。

我随着表的增长调整索引，但我正在为我的聚集索引寻找一个好的起点。

-- OPTION #1: clustered index on primary key (so, unique)
CREATE TABLE dbo.SaleItems
(
SaleItemID INT IDENTITY PRIMARY KEY CLUSTERED,
SalesCategoryID int NOT NULL,
SaleItemName varchar (100) NOT NULL,
SalesPrice smallmoney NULL
);


-- OPTION #2: clustered index on column that matches common filter (not unique)
CREATE TABLE dbo.SaleItems
(
SaleItemID INT IDENTITY PRIMARY KEY,
SalesCategoryID int NOT NULL,
SaleItemName varchar (100) NOT NULL,
SalesPrice smallmoney NULL
);
CREATE CLUSTERED INDEX IX_SaleItems_SalesCategoryID ON dbo.SaleItems (SalesCategoryID); 

在我的存储过程中，当业务规则被破坏时，我会引发一个错误，该错误会冒泡到 C# 客户端应用程序并显示给用户。例如

RAISERROR('Hey, you cannot do that because blah blah blah', 16, 1);

我想将我引发的错误与其他 SQL Server 错误区分开来，因为我只想显示我的错误。

我认为这些是向客户端应用程序发送消息的唯一方法，这是要显示的用户消息：严重级别、状态、返回代码。但我认为我应该离开严重级别。

• 如何告诉我的客户端应用程序？
• 我应该使用什么尚未使用的代码或号码？
• 或者有没有我没有考虑过的另一种方式？

或者我应该这样做：

THROW 50000, 'Hey, you cannot do that!', 1;  

编辑（2022 年 4 月 13 日） 我问 Erland Sommarskog，他的回答帮助我意识到，如果你使用这个

RAISERROR('Hey, you cannot do that because blah blah blah', 16, 1);

...然后客户端应用程序将始终获得 50000 作为错误号。使用 RAISERROR，您可以使用参数化消息。您只需要注意 RAISERROR 不会退出批处理。所以，对我来说，RAISERROR 赢了。

我正在构建一个数据仓库（SQL Server 2012，Kimball Dimensional modeling，750GB），它将向报告（SSRS）、多维数据集（SSAS）和各种数据馈送提供数据。

我打算使用索引调整工具（可能是sp_BlitzIndex），但我该如何开始呢？我是否从没有索引开始，然后让 sp_BlitzIndex 告诉我一段时间后要使用哪些索引？还是从明显的索引开始，然后使用 sp_BlitzIndex 构建？

我计划在每个主键上添加一个聚集索引，在每个外键上添加一个非聚集索引——然后让 sp_BlitzIndex 建议不太明显的选择。但也许我应该把它全部交给 sp_BlitzIndex。

我正在构建一个数据库来管理 POS 系统（菜单项、收银员等）的定义。它将包括许多商店和许多版本。

因此，典型的表格将如下所示（MenuItems 表格）...

StoreID PK
VersionID PK
MenuItemID PK
MenuItemName

但我想将 StoreID 和 VersionID 合并为一个表示商店和版本的 ID（因此，商店 101 的版本 5）。所以，我简化了每个表的主键（因为每个表都需要这个）

然后让我的桌子看起来像这样......

SomethingID PK
MenuItemID PK
MenuItemName

请帮我命名 StoreIDAndVersionID 字段。我不知道该怎么称呼它。

我们有一套餐厅网络应用程序，将数据存储在数据库服务器上的 SQL Server 2012 中。我们现在已经开始将用于报告的数据移动到单独的数据仓库服务器上。数据需要在更新/创建后很快进入数据仓库。

知道何时将事务移动到数据仓库（和事实表）很容易——我们定期或在某些事件发生时（比如经理完成某事）这样做。

但是我怎么知道何时将定义移动到数据仓库（和维表）？我们将定义存储为 SCD 类型 1。

我们正在考虑...

1. 按照计划，使用维度检查数据库服务器上的所有定义并更新任何更改。将交易分配给“未知”是尚未到达的维度。
2. 在所有定义表上放置触发器并在发生更改时更新数据仓库
3. 更新存储过程以在每次进行更改时更新数据仓库
4. 使用 Microsoft Sync Framework 之类的东西，并在其中合并转换。

数据库和数据仓库服务器位于不同的服务器上——我们计划将其迁移到 SQL Azure。

那么，我如何知道何时运行维度的 ETL？而且，任何关于技术的建议都会有所帮助（我们目前正在使用 SQL Server 链接服务器）。

当我运行此删除时：

DELETE FROM ETLHeaders WHERE ETLHeaderID < 32465870

...它删除了 39,157 行。它应该很简单，因为它是在 ETLHeaderID 上删除，它是聚集索引和主键。但是（根据执行计划）它似乎达到了 361,190 行并使用了其他索引。该表确实有一个 XML 数据类型的字段（以防影响此 DELETE）。

有什么想法为什么以及如何加快此删除速度？

此处执行计划： http : //sharetext.org/qwDY 此处表架构：http: //sharetext.org/Vl9j

谢谢

对于 SQL 数据收集器：

您是否需要在要从中收集数据的服务器上安装 SSIS（SQL Server 集成服务）。或者这些包可以从另一台服务器运行——比如 MDW 数据库所在的服务器。