0

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

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

在我看来，有两种选择：

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

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

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

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

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

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

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

4

2 回答 2

0

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

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

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

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

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

于 2017-05-08T14:55:22.307 回答
0

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

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

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

于 2017-05-02T21:29:00.870 回答