我正在设计一个PostgreSQL数据库，该数据库接收来自许多传感器源的读数。我已经对该设计进行了很多研究，我正在寻找一些新的建议，以帮助我摆脱困境。
需要明确的是，我并不是在寻求描述数据源或任何相关元数据的帮助。我专门试图弄清楚如何最好地存储数据值(最终是各种类型)。
传入数据的基本结构如下:
这种数据布局的显着特征是，我有许多通道将数据点与带有时间戳和索引号的单个记录相关联。
现在，描述数据量和常见的访问模式:
我还应该提到，每个记录器时间戳都会因时间调整而有所变化，并将在不同的表中进行说明，该表显示了服务器的时间读取，记录器的时间读取，传输延迟，时钟调整以及调整后的时钟值。对于一组记录器记录/时间戳(取决于检索)，将发生这种情况。这是我在下面使用
RecordTable的动机，但是现在只要我可以从某处引用(记录器，时间，记录)行来更改相关数据的时间戳，否则现在就不用担心了。我考虑了很多模式选项，最简单的类似于混合EAV方法，其中表本身描述了属性，因为大多数属性只是一个称为“值”的实际值。这是基本布局:
RecordTable DataValueTable
---------- --------------
[PK] id <-- [FK] record_id
[FK] logger_id [FK] channel_id
record_number value
logger_time
考虑到
logger_id，record_number和logger_time是唯一的，我想我在这里使用代理键，但是希望节省空间的理由在这里有意义。我还考虑过在DataValueTable中添加一个PK ID(而不是PK是record_id和channel_id)，以便引用其他表中的数据值，但是我现在试图抵制使该模型“过于灵活”的冲动。但是，我确实想尽快开始使数据流动，并且在以后需要添加其他功能或结构不同的数据时不必更改此部分。最初，我为每个记录器创建记录表，然后为每个通道创建值表，并在其他地方(在一个地方)描述它们，并用 View 将它们连接在一起，但是由于我重复了同样的事情，所以感觉“不对”多次。我想我想在太多的表和太多的行之间找到一个快乐的介质，但是对较大的数据(
DataValueTable)进行分区似乎很奇怪，因为我很可能在channel_id上进行分区，因此每个分区的值都相同每行。同样，在这方面进行分区在每次添加通道时都需要一点工作来重新定义主表中的检查条件。按日期分区仅适用于RecordTable，考虑到它相对较小(使用5个记录器每天7200行)，实际上并没有必要。我还考虑将上面的内容与
channel_id上的部分索引一起使用，因为DataValueTable会变得很大，但是通道ID的集合仍然很小，但是我不确定在多年之后它能否很好地扩展。我已经对模拟数据进行了一些基本测试，并且性能只是一般的，我希望它随着数据量的增长而保持卓越。同样，有些人表示关注清理和分析大表以及处理大量索引(在这种情况下最多为250)。在一个非常小的方面，我还将跟踪该数据的变化并允许进行注释(例如，一只鸟被传感器卡住了，因此这些值已被调整/标记等)，因此在考虑时请记住这里的设计，但现在是另外一个问题。
我的经验/技术水平的一些背景，如果可以帮助我了解我的来源:我是CS博士学位的学生，在研究过程中，我定期使用数据/数据库。但是，在为客户(这是业务的一部分)设计一个健壮的数据库(具有超长的使用寿命和灵活的数据表示)方面，我的实践经验受到一定的限制。我认为我现在的主要问题是我正在考虑解决该问题的所有角度，而不是专注于解决问题，而且我根本没有看到“正确”的解决方案。
因此，总而言之，我想这些是您的主要查询:如果您已经做了类似的事情，那么对您有用的是什么？我在这里提出的各种设计没有看到哪些好处/缺点？给定这些参数和访问模式，您如何设计这样的东西？
我很乐意在需要时提供澄清/详细信息，并在此先感谢您的支持。
最佳答案
在关系数据库中提供所有这些完全没有问题。 PostgreSQL不是企业类，但是它无疑是更好的免费SQL之一。
需要明确的是，我并不是在寻求描述数据源或任何相关元数据的帮助。我专门试图弄清楚如何最好地存储数据值(最终是各种类型)。
那是你最大的障碍。与允许分解和隔离组件的分析/设计的程序设计相反，数据库需要设计为单个单元。规范化和其他设计技术需要同时考虑整体和组件。数据，描述和元数据必须一起评估，而不是分开评估。
其次，当您从代理键开始时，意味着您知道数据以及它与其他数据的关系，这将阻止您对数据进行真正的建模。
我已经回答了一组非常相似的问题，巧合的是，数据也非常相似。如果您可以先阅读这些答案，那么将为我们节省很多在您的问题/答案上的键入时间。
Answer One/ID Obstacle
Answer Two/Main
Answer Three/Historical
关于database - 使用定期传感器数据设计数据库，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5224813/