小编cri*_*vin的帖子

在以下场景中寻找与优化设计相关的一些建议。

1. 有一个 Cases 表（代表库存的情况）
2. 有一个 LocationInventory 表（代表有库存的位置）
3. 然后我有一个或多个 InventoryNeed 表（这是问题的关键），需要考虑案例和位置。

选项A：

一张表有 2 个外键列，其中将填充一个且仅一个外键。

表：库存需求

1. 案例 ID (FK)
2. 位置库存 ID (FK)
3. 所需数量

在这种情况下，CaseId 或 LocationInventoryId 将为 null，而另一个已填充。

选项B：

每种需求类型有两个表，经常通过 UNION 来获取摘要数据。

表：库存需求案例

1. 案例 ID (FK)
2. 所需数量

表：库存需求地点

1. 位置库存 ID (FK)
2. 所需数量

选项C：

一张没有参照完整性的表。

表：库存需求案例

1. NeedType（案例或位置的值）
2. NeedId（表示基于 NeedType 的 Case 或 LocationInventory 的主键）。
3. 所需数量

最终获胜者是？我可能会将范围缩小为 A 或 B 以确保数据完整性......但不确定哪个是最好的。或者也许有一个选项 D（例如创建具有公共列的基表......）

更新的场景

当我昨晚发布此内容时，我只考虑下游，但也存在对这些相同表的上游依赖关系。我画了一些图，希望能更好地解释它。随着这个出现，选项 B 开始爆炸所涉及的表的数量，在阅读了这个 SE 答案之后……我现在更倾向于 A。

下面的图片。然后红色代表库存需求，绿色代表满足这些需求的库存来源。黄色是当前的问题......如何有效地连接红色和绿色。

选项 A 图片 - 有更多解释和背景

选项 B - 为清楚起见删除了上下文

我最近停止接收 sql 代理作业失败通知。经过调查，报告的错误是：

The mail could not be sent to the recipients because of the mail server failure. (Sending Mail using Account 1 (2017-08-16T02:40:14). Exception Message: Could not connect to mail server. (No such host is known).

邮件帐户设置没有改变，我确认它看起来是正确的。此外，我可以使用SSMS 中的“发送测试电子邮件...”功能成功发送和接收电子邮件。那么为什么工作不能发送电子邮件呢？

由于“发送测试电子邮件...”功能将电子邮件排队，因此以这种方式发送它与发送它的作业相比似乎没有权限问题。此外，这表明这不是防火墙问题。所以唯一的区别是一天中的时间......作业在半夜运行......但我想不出任何系统配置会在那时发生变化。

有什么其他想法要检查吗？

我正在尝试创建一个查询来计算库存中所有项目的“可销售”数量。在这种情况下，一个项目可以有当前可用的库存，但也可以是一个套件，它由可以组装以形成成品的原材料组成。因此，可供出售的是当前可用的成品 (FG) 数量加上可以制成 FG 的最少组件。

例子：

假设我们正在销售由笔记本电脑和手提包组成的笔记本电脑套件。如果我们已经制作了 2 个套件，以及 6 台笔记本电脑和 3 个手提袋，那么我们可以出售的这些套件总共是 2 + 3 = 5。在这种情况下，手提袋是限制因素。尽管我们有 6 台笔记本电脑，但由于包包限制了我们，我们只能多制作 3 个套件。

我已经走了这么远，计算从最低级别 2 到级别 1，但级别 0 不正确。因此，在这种情况下，笔记本电脑套件的计算是正确的（手头有 11 个 + 我们可以再制造 4 个 = 15 个可供出售）。但顶级笔记本电脑和包包是不正确的。最高级别（笔记本电脑和包套件）的直接子代的最少可销售量是 15 + 3 现有套件 = 18，而不是 14。

我在想也许我需要添加第二个递归 CTE 而不是我在最终选择中的左连接？

SQL小提琴

CREATE TABLE Item (
  Id INT,
  ParentId INT,
  DisplaySeq INT,  
  DisplayText VARCHAR(30),
  OnHandQty INT
  );

INSERT INTO Item (Id, ParentId, DisplaySeq, DisplayText, OnHandQty) VALUES
(9, NULL, 0, 'Laptop & Bag Kit', 3), …

我们的 SQL Server 数据库中的两个表相当于 500M 行和 350GB 的数据。磁盘空间是我们保留备份和执行备份的时间的问题。我们计划截断这两个表。

我知道要回收磁盘空间，我们需要在截断后缩小数据库，然后进行索引重建以修复碎片索引。但由于我们不确定重建需要多长时间（我们现在正在 Azure 中启动一个测试服务器 VM 进行测试），同时我们正在寻找增量收益。在截断之后（在收缩和重建之前），备份时间和生成的备份文件大小（7z 压缩之后）是否会因此而显着减少？

我知道这里面有很多变量，我不是在寻找精确的分钟数：秒 :) 我已经阅读了许多资源，这些资源声明 aTRUNCATE使用的资源比 a 少得多DELETE，因此执行速度更快。但是没有提到数量级。由于 aTRUNCATE是 DDL（数据定义语言）操作而不是 DML（数据操作语言）操作，并且只有系统表是事务的一部分，因此我认为它不会花费很长时间。

任何有经验的人都可以使用接近这种大小的桌子来做这件事，可以提供一些见解吗？我们最多谈一分钟，最多一个小时，几天，几周？