“传感器系统”的最佳数据库设计
我正在做功课......
我必须做一个车辆跟踪系统。我想到了这三种设计。你怎么认为？
我的数据库架构
有意见吗？
I'm doing a schoolwork and..
I have to do a vehicle tracker system. I thought of these three designs. What do you think?
My database schemas
Opinions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您始终在一次测量会话中测量并存储所有参数，那么请选择
1设计。仅当属性很少存储和/或很少需要时，将属性移至单独的表中才有意义。
如果您有单独的位置和温度传感器，请选择设计
3。这是最有可能的，因为位置是由
GPS跟踪器测量的，温度和油位是由车辆传感器测量的，它们是单独的设备，并且测量是在不同的时间进行的。< /p>您甚至可能需要为每个传感器添加一个单独的表格（即，如果不同的传感器在不同时间测量气体和温度，则为它们制作两个表格）。
如果您使用的液体列表在设计时未知（即某些第三种液体），则将
liquid移动到单独的表中（如设计2）是有意义的，如氢或氦 3 或他们将发明的任何东西将被车辆使用，您将需要跟踪它而不重新设计数据库）。当然，这不太可能发生。
If you always measure and store all parameters within one measuring session, then go for the design
1.Moving the attributes into separate tables only makes sense if the attributes are rarely stored and/or rarely needed.
If you have separate sensors for position and temperature, then go for design
3.This is most probable, since the position is measured by a
GPStracker and temperature and oil level are measured by the vehicle sensors, which are separate devices and the measurements are performed at separate times.You may even need to add a separate table for each sensor (i. e. if different sensors measure gas and temperature at different times, then make two tables for them).
Moving
liquidinto a separate table (as in design2) makes sense if the list of the liquids you use is not known in design time (i. e. some third liquid, like hydrogen or helium-3 or whatever they will invent will be used by the vehicles and you will need to track it without redesigning the database).This is not a likely scenario, of course.
如果您同时从传感器读取数据，那么第二种设计对我来说看起来有点矫枉过正。如果您在不同时间阅读该信息，则将信息分开是有意义的。
我建议第一个设计。
if you're reading from the sensors at the same time the second design looks like an overkill to me. It would make sense to keep information separate just if you read that information at different times.
I would suggest the first design.
您的应用程序需要处理两种类型的事物
有几件事需要考虑：
- 我们如何找到抽象传感器概念的方法？我们的想法是，我们可以通过传感器实例的属性来识别和处理它们，而不必知道它们在数据库中的位置。
- 最好将给定时间戳的所有测量值保留在单个“读取”记录中，或者每个传感器每次读取都有一个记录，即使多个测量值成组出现。
最后一个问题的快速答案是每条记录的单个读取事件似乎更灵活；我们将能够以完全相同的方式处理同时系统轮询的两组测量，以及与前者异步的其他测量。即使现在所有测量结果都是同时进行的，在不改变数据库模式的情况下轻松添加传感器并以类似方式处理它们的潜力也是很有吸引力的。
也许以下设计更接近您的需要：
tblSensors SensorId PK Name clear text description of the sensor ("Oil Temp.") LongName longer description ("Oil Temperarure, Sensor TH-B14 in crankshaft") SensorType enumeration ("TEMP", "PRESSURE", "VELOCITY"...) SensorSubType enumeration ("OIL", "AIR"...) Location enumeration ("ENGINE", "GENERAL", "EXHAUST"...) OtherCrit other crietrias which may be used to identify/seach for the sensor. tblReads Readid PK DateTime SensorId FK to tblSensors Measurment INTeger value Measurement2 optional extra meassurement (maybe to handle say, all of a GPS sensor read as one "value" Measurement3 ... also may have multiple columns for different types of variables (real-valued ?)除了上面的之外，您还有一些表，其中定义了各种类型传感器的“枚举”，并且与应用程序逻辑的结合将通过这些枚举的类似助记符的“键”的方式。例如。
这不会阻止您也通过 ID 调用传感器，并在同一结果行上对读取进行分组。例如。
Your application needs to deal with two types of things
There are a few things to think about:
- How can we find ways of abstracting the sensor concept? The idea is that we could then identify and deal with sensor instances through their properties, rather than having to know where to they are found in database.
-Is is best to keep all measurements for a given timestamp in a single "Read" record or to have one record per sensor, per read, even if several measurements come in sets.
A quick answer to the last question is that the single read event per record seems more flexible; we'll be able to handle, in the very same fashion, both groups of measurements that are systematically polled at the same time, and other measurements that are asynchonous to the former. Even if right-now, all measurements come at once, the potential for easy addition of sensors without changing the database schema and for handling them in like-fashion, is appealing.
Maybe the following design would be closer to what you need:
tblSensors SensorId PK Name clear text description of the sensor ("Oil Temp.") LongName longer description ("Oil Temperarure, Sensor TH-B14 in crankshaft") SensorType enumeration ("TEMP", "PRESSURE", "VELOCITY"...) SensorSubType enumeration ("OIL", "AIR"...) Location enumeration ("ENGINE", "GENERAL", "EXHAUST"...) OtherCrit other crietrias which may be used to identify/seach for the sensor. tblReads Readid PK DateTime SensorId FK to tblSensors Measurment INTeger value Measurement2 optional extra meassurement (maybe to handle say, all of a GPS sensor read as one "value" Measurement3 ... also may have multiple columns for different types of variables (real-valued ?)In addition to the above you'd have a few tables where the "enumerations" for the various types of sensors are defined, and the tie-in to the application logic would be by way of the mnemonic-like "keys" of these enumerations. eg.
This would not prevent you to also call the sensors by their id, and to group reads on the same results line. eg.