使用代码列与扩展表查询 SQL答案

【问题标题】：Querying SQL using a Code column vs extended table使用代码列与扩展表查询 SQL
【发布时间】：2020-08-13 08:18:15
【问题描述】：

我正在一个 sql 数据库（我估计大约 10 万条记录）上设置一个相当大的数据集（目录）来存储有关产品的信息。每个产品都有大约 20-30 个属性，所以这基本上意味着 20-30 列。系统设置为使这些属性中的每一个实际上都链接到一个代码，因此每个产品的特征在于连接所有这些属性的唯一字符串（字符串必须是唯一的，如果两个产品代码相同，则两个产品实际上是相同的产品）。我想弄清楚的是，如果 sql-wise 将目录存储为 20-30 列的表有什么不同，或者我最好只使用 1 列的代码并从代码中解码属性。不同之处在于，在一种情况下我会这样做

SELECT * FROM Catalogue WHERE Color='RED'

对

SELECT * FROM Catalogue WHERE Code LIKE '____R____________'

此外，它可能更容易检查产品是否已经存在，因为我只比较单个列与 20-30 列。我也可以在完整的表中添加一个额外的列来存储代码，并在执行一项操作时使用一种方法，在执行另一项操作时使用另一种方法。

我对 SQL 引擎的工作原理几乎一无所知，所以我可能完全不理解这里的推理。

【问题讨论】：

如果每个“代码”是一个单独的实体，并且要单独查询，它们应该单独存储。上面的前一个查询具有正确的索引，可能只需要查找相关行。然而，后一个查询不是 SARGable，因为前导通配符，因此需要扫描整个表；性能要差得多，
第一个近似值，将逻辑上不同的数据片段组合到一个必须再次解码的列中，您的情况几乎总是更糟。打包/解包值所需的操作会减慢查询速度并阻止使用索引。在极少数情况下它有助于存储，但即使在这种情况下，您通常最好还是使用数据压缩（无论是行还是页）。如果经常将组合列本身作为一个整体进行查询，请将其设置为带有索引的计算列。
完全不相关，但是：100k 行现在被认为很小。绝对不是“相当大”

标签： sql sql-server sql-like

【解决方案1】：

code 方法似乎很愚蠢。为什么我会这样说？

您有几十个带有属性的列，并且您知道它们是什么。为什么不将这些信息包含在数据模型中。

我也很高兴你将如何区分这些比较：

WHERE Code LIKE '____R____________'
WHERE Code LIKE '___R_____________'
WHERE Code LIKE '_____R___________'
WHERE Code LIKE '____R___________'

这似乎是你未来余生一半时间用于调试的秘诀——如果不是你的代码，那么就是别人的代码。

而且，通过单独的列，您可以为常用组合创建索引。

如果不是所有行都具有所有属性——或者如果属性可以在将来扩展——你可能需要一个结构，每个属性都有一个单独的行：

entityId     code      value
   1         Color     Red

这称为实体属性值 (EAV) 模型，在某些情况下是合适的。

【讨论】：

是的，我意识到代码方法有点奇怪，问题是我实际上必须拥有代码，所以我想我不妨使用它，代码应该有点标准（例如前三个字母是颜色，接下来的三个是材料......）所以我想创建一个从过滤器列表构建字符串的方法不会那么难，代码实际上可能用连字符或类似的东西分隔（我仍然需要收到详细信息）。感谢您的回复，我会按照标准方式进行：）
另外顺便说一句，属性不应该改变，它们应该总是被填充，但是就像额外的信息在 EAV 模型中查询不慢一样？（假设我必须在用户填写表单时向他提出选项，建议基于类似产品的常用属性值，因此需要相当快的响应时间。
@NicoloCastro 。 . .如果您事先知道所有属性并且它们不会改变，那么 EAV 模型提供的灵活性就没有帮助。而且这样的数据结构通常在性能方面效率较低。