我将在 SQL Server 中为客户端创建几个表。对这个问题特别感兴趣的是FactStoreSale要创建表，并DimProduct在其中的第一个表将包括所有门店的销售情况，并包括例如StoreKey，DateKey，TimeKey，ProductKey和销售数据。
该DimProduct表将在关于产品，使用补充数据，即ProductName，ProductGroup，ProductCategory等这个表将在价格等每个商店而言缓慢改变的尺寸和存储产品的历史。该表将包括列FromDate和ToDate，它们分别描述了输入数据的时间和替换数据的时间（默认值为 2999 年，ToDate直到插入产品的新更新）。
我相信这是很常见的。但是，ProductKeys来自底层数据库的非常复杂的字符串，例如140-xx4449CH-4.44,9.
在我看来，我的替代方案是Checksum在 SQL Server 中使用将复杂字符串转换为整数，并将它们存储在单独的列中，ProductKeyInt
并在执行 JOINS 时使用这些列。但是校验和不保证唯一的整数值，这可能会导致问题。当我在 Virtual PC 和我自己的 PC 上尝试 Checksum 时，对相同值执行 Checksum 会返回不同的结果，这也是一个问题。我相信这两者一起排除了校验和，除非可以以某种方式操纵它以使其更独特？
另一种选择是使用更复杂的函数来确保将字符串值转换为整数，例如在我的问题中提供的此处。诸如这样的解决方案但也有问题，该值100-xx3和1003将例如得到同样的结果。从某种意义上说，如果对 SQL 不那么精通的人需要尝试查找使用该函数的 Query 的任何问题，则可能很难理解正在发生的事情，这也很复杂。
我的第三个选择似乎是使用该DimProduct表并首先从 SQL 代理更新该表，然后在该表上使用索引键并将该索引用作FactStoreSale表中的 ProductKeyInt（例如 ProductKeyInt 将是某种子查询FactStoreSale获取与 …
我有一种情况，我对 TempDB 的大小有限制，不能超过 350 GB。我autogrowth 10在 TempDB 上使用（百分比），因为我读到它应该是超过 500 MB 的数据库的最佳实践。
当我使用
dbcc checkdb with estimateonly
在每个数据库上，我注意到 TempDB 的估计需求比我目前的需求低得多。将 返回的值相加dbcc checkdb with estimateonly得到大约 75 GB 的值。
TempDB 的大小目前为 300 GB。我无法进一步增加 TempDB 的允许大小。
我听说我们公司以前有一个 SQL 作业，如果它超过某个值，它会自动缩小 TempDB，但它没有在我们的新环境中使用。然而，我很矛盾，对缩小 TempDB 过于宽松可能会导致问题。
使用这篇文章中的信息，如果当前大小超过 200 GB 左右，将 TempDB 自动收缩到 200 GB 大小是否存在任何重大风险，看到dbcc checkdb with estimateonly返回的估计最小大小为 75 GB，这将导致这一个相当高的相对缓冲？
我读过这不是缩小 TempDB 的最佳做法，但在这种情况下，参考 TempDB 的估计最小大小，它可能更“合法”吗？
编辑
我做了以下查询，例如，internal object MB space, internal object dealloc MB space, statement text（查询）, total …