Лучшее проектирование баз данных для “системы датчика”

если вы одновременно считываете данные с датчиков, второй вариант мне кажется излишним. Было бы разумно хранить информацию отдельно, если бы вы читали ее в разное время.

Я бы предложил первый вариант.

Основная причина, по которой я могу думать, заключается в том, что вы можете захотеть иметь некоторые методы, специфичные для коллекции изображений, которые работают с самой этой коллекцией. Затем я бы использовал класс ImageCollection для хранения этих методов. Классическая инкапсуляция.

Кроме того, в стороне, вам действительно следует предоставлять только метод получения для этой коллекции и инициализировать поле поддержки только для чтения фактической коллекцией. Вероятно, вы хотите, чтобы люди добавляли / удаляли элементы из коллекции, а не заменяли все:

class Product {
    private readonly Collection<Image> _images;
    public Product() { _images = new Collection<Image>(); }
    public Collection<Image> Images { get { return _images; } }
}

-Oisin

Your application needs to deal with two types of things

• Sensors = which type, where in the engine, and even parameters such as polling frequency and such..
• Reads = individual time-stamped recordings from one (or several ?) sensors.

There are a few things to think about:
- Как мы можем найти способы абстрагирования концепции сенсора ? Идея состоит в том, чтобы затем мы могли идентифицировать экземпляры датчиков и работать с ними через их свойства, вместо того, чтобы знать, где они находятся в базе данных.
-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.

SELECT S.Name, R.DateTime, R.Measurement
FROM tblReads R
JOIN tblSensors S ON S.SensorId = R.SensorID
WHERE S.SensorType IN ('Temp', 'Pres')
  AND S.Location = "ENG"
  AND R.DateTime > '04/07/2009'
ORDER BY R.DateTime

This would not prevent you to also call the sensors by their id, and to group reads on the same results line. eg.

SELECT R1.DateTime, R1.Measurement AS OilTemp, R2.Measurement AS OilPress,
       R3.Measurement AS MotorRpms
FROM  tblReads R1
LEFT OUTER JOIN tblReads R2  ON R1.DateTime = R2.DateTime
LEFT OUTER JOIN tblReads R3  ON R1.DateTime = R3.DateTime
WHERE R1.SensorId = 17 
  AND R2.SensorId = 11 
  AND R3.SensorId = 44 
  AND R1.DateTime > '04/07/2009' AND R1.DateTime < '04/08/2009'
ORDER BY R3.Measurement DESC -- Sorte by Speed, fastest first