mysql - 单列与多列设计(针对非主键列)

Question

在数据库表设计中，对于event-log类型的数据增长，下列哪项设计更好

Design 1) Numeric columns(Long) and character columns (Varchar2) with Index:

..(pkey)|..|..|StockNumber Long | StockDomain Varchar2 |...
..      |..|..|11111            | Finance
..      |..|..|23458            | Medical

Design 2) Character column Varchar2 with Index:

..(pkey)|..|..|StockDetails  Varchar2(1000) |..|..
..      |..|..|11111;Finance                |..|.. 
..      |..|..|23458;Medical                |..|..

设计优势:第一个设计非常具体，第二个设计更通用，可以容纳更通用的数据。在这两种情况下，列都有索引。

存储:第一个设计索引比第二个需要更少的存储空间性能:相同？

我有一个关于性能与灵 active 的问题。显然，首先设计更好。但是第二个设计是更通用的目的。让我知道你的见解

注意:为了更清楚地编辑问题。

Answer 1

一般来说，具有离散列是更好的方法，原因如下:

1. 数据类型 - 您可以保证您保存的数据格式正确，至少就非字符串列而言，如果它是 bigint/long，您的 stockNumber 将始终是一个数字，尝试设置它对其他任何东西都会导致您的插入/更新错误。作为冒号分隔值 (CSV) 字符串的一部分，当它是字符串的一部分时，可能会出现错误数据。

2. 查询 - 查询单个列必须使用 LIKE 完成，因为您正在寻找单个列字符串的子字符串。如果我查找 WHERE StockDetails LIKE '%11111%'，我会找到第一行，但我可能会找到另一行，其中该列中不同字段中的美元值为 $11111。对于离散列，您的查询将是WHERE StockNumber = 11111，保证它仅在该列中找到数据。

3. 使用数据 - 一旦找到所需的行，就必须读取数据。这意味着将您的 CSV 解析为单独的字段。如果其中一个字段中有冒号，并且未正确转义，则其余数据将被错误解析，并且您仍然需要保证相同顺序的值，留下空白部分 ;; 列中的空值。

在存储 CSV 和单独的列之间有一个中间地带。我已经看到并且实际上正在做一个主要项目，数据以 json 形式存储在表中。使用 json 你有属性名称，所以你不关心字段在字符串中出现的顺序，因为域仍然永远是域，你不需要在条目中的任何非标准字段(比如只存在的属性医学领域)将不存在而不是需要一个空白的双冒号，并且 json 的解析器以我能想到的所有语言存在，你会连接到你的数据库，不需要手动编码来解析你的 CSV 字符串.例如，上面给出的 StockDetails 将如下所示:

+--------------------------------------+
|             StockDetails             |
+--------------------------------------+
| {"number":11111, "domain":"Finance"} |
| {"number":23458, "domain":"Medical"} |
+--------------------------------------+

这解决了上面的问题 2 和 3:

1. 您现在将查询编写为 WHERE StockDetails LIKE '%"number":11111，包括 json 属性名称可确保您不会在字符串的其他任何位置找到数据。
2. 您无需担心字段乱序或字符串中缺失导致数据无法使用，使用 json 为您提供键/值对，您需要做的就是处理键不存在的空值'存在。这还可以让您轻松添加字段，添加新的 CSV 字段可能会破坏您的代码来解析它，现有数据的值数量将会关闭，因此您可能需要更新所有行，但是因为在 json 中您只存储非空字段，新字段将被视为现有数据上的任何其他空值。