建立设备数据库。将所有设备属性放在一个表中还是在多个单独的表中更好？

Question

我正在构建一个用于监控设备的数据库，但我陷入了僵局。

我有 40 种不同类型的设备，每一种都记录不同的信息，并有一些共同点（例如设备名称、采样日期）但大多不同的属性（例如 signal_50_100Hz、device_arm_attached）。

在我看来，有两种选择：

1. 构建一个包含并耗尽所有设备的所有属性的大表。

   • 缺点：并非所有设备都具有所有属性的值，并且并非所有属性都与所有设备相关。大部分表格可能最终是空的，我可能必须建立一个表格来记录每个设备的属性名称，以便生成合理的输出。
   • 优点：拥有一张表可以极大地简化事情，使以后更容易聚合和汇总值，编写的 SQL 更少，更通用，更容易理解。

2. 为每种设备类型创建一个单独的表，在每个表中分别列出每个属性。

   • 缺点：每次拿到新设备都需要编写自定义SQL，rehash整个系统，没有通用接口。需要独立构建和管理的大量表。
   • 优点：所有内容都布局简洁，如果需要，可以解耦以独立存在。没有额外的负担，并且一种设备类型不会通过通用属性集与其他设备类型耦合。

此数据库的目的是将来自这些监控设备的信息持续汇总到一个视图中，然后根据分析人员的需要进行查询。

我喜欢为每个设备创建不同的表，然后使用通用视图将这些表中的相关数据聚合成更可用和更通用的形式。这将允许我保留数据（为了保留），并根据需要从一个通用的、抽象的层、一个大视图中聚合它。

您认为这种方法有什么问题吗？ 哪种方法更有意义？ 我还可以采用哪些其他策略？ 有人对如何更好地解决此问题有任何一般性建议吗？

Answer 1

在大多数情况下，如果您添加一个新设备并且它具有新属性，并且您打算让您的应用程序以某种方式使用这些属性，那么您将不得不编写代码。没有办法避免这种情况。即使你有一个可以容纳任何东西的灵活的表结构，除非你对它做某事，否则坚持某物是没有意义的，并且使用它做某事的软件需要修改才能做某事。因此，“脱钩”和永远不必再改变任何东西的想法只是一个抽象的梦想。

如果您打算保留数据，但根本没有任何计划对其进行任何操作（出于存储目的而存储，例如出于可听性或合规性目的），您可以存储它都在一个灵活的字段中（比如一个大的 varchar）作为 XML 或 JSON 结构。那将是完全灵活的。

在任何一种情况下，您都希望从一个表开始。该表可以包括每个设备的唯一主键、名称或序列号、型号，然后是所有设备通用或有用的一系列列。如果某个属性很常见但仅存在于 90% 的设备上，则可以为该属性创建一个列并在它不适用时将其保留为空。如果一个属性或一组属性只属于一小部分设备，我会考虑将它们分成一个或多个单独的表，但具有相同的主键。为了帮助您的代码与架构更改隔离开来，您可以构建一个视图，以一种有用的方式将表连接在一起，并将该视图用作存储过程或选择语句的基础。

Answer 2

这是关系数据库中多态性的古老问题。有几种模式需要考虑。

一个表，其中包含所有设备的所有列的并集。有点糟糕，因为会有很多不相关的列的空值，所以不可能添加应该应用于某些设备的 NOT NULL 约束。此外，在添加需要新列的新设备时，您必须更改架构。

每个设备都有一个表，然后将它们合并到一个视图中以查询所有设备。有点糟糕，因为您必须添加一个新表并修改新设备的视图。

EAV 模式。有点糟糕，因为它会影响查询性能，并且不可能添加适用于某些设备的 NOT NULL 约束。

一个表，其中包含一个 JSON 列，用于表示因设备而异的属性。这越来越接近数据的自然表示，但它有点糟糕，因为您必须管理值的任何索引。 https://dev.mysql.com/doc/refman/5.7/en/create-table-secondary-indexes.html#json-column-indirect-index