Как далеко идти с ограничениями базы данных?

Этот вопрос связан с другим вопросом, который я задал. В моем другом вопросе я прошу мнения людей о трех разных способах создания базы данных. Самый чистый способ, которым я могу думать об этом без (практически) повторения таблиц и странных понятий, таких как "супер таблицы", - это вариант 2:

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

Чтобы объяснить, почему это проблема, я объясню, как работает система:

Местоположение может содержать множество "живых датчиков", но только 1 регистратор. По этой причине я помещал атрибуты регистратора в таблицу местоположений (это было эффективно с отношением 1 к 1). Регистратор собирает показания до тех пор, пока их не соберет позже, живые датчики мгновенно передают показания через сеть, и у них есть дополнительные атрибуты, такие как сетевые подчиненные устройства, которые имеют атрибуты сетевых адресов.. настолько сильно отличаются от регистраторов (я пытался обрабатывать регистраторы как датчики в одной точке, не получится хорошо).

Когда датчик или регистратор выходит за пределы диапазона (обозначается показанием), система генерирует предупреждение. Предупреждение относится только к этому датчику и считается активным до тех пор, пока показания для этого датчика (или регистратора) не покажут, что он находится в зоне действия. До этого времени показания, в которых датчик выходит за пределы диапазона, "привязаны" к тому же предупреждению.

Итак, как вы можете видеть, одно предупреждение должно иметь только показания для одного и того же сенсора, связанного с ним, однако мой проект выше позволяет различать показания от разных датчиков и регистраторов, связанных с одним и тем же предупреждением, - следует ли мне беспокоиться о том, что Я так не ограничил это? Другая проблема заключается в том, что он позволяет оповещения существовать без каких-либо чтений.

Отсюда мой вопрос; насколько далеко следует идти с ограничениями или сгибать дизайн в соответствии с этими ограничениями? Мне нравится дизайн выше, потому что он прост: предупреждения могут иметь показания датчиков и показания регистратора, поэтому это простое отношение, чтобы связать их.

Я не могу не думать, что мне тоже не хватает трюка - есть ли гораздо лучший способ сделать этот проект? Я крутился с ним целую вечность и всегда кажется компромиссом (если я не повторяю все таблицы предупреждений для разных типов чтения).

Ответы

Ответ 1

Должен ли я беспокоиться, что я так не ограничил это?

Да.

Вы совершили две основные ошибки.

Нажатие Id iot клавиш на все, что движется.

Это затрудняет вашу способность моделировать данные как данные (не как строки, которые не имеют смысла, но с искусственно соблюдаемой уникальностью) и раскрывают идентификаторы; и Dependdencies (например, датчик зависит от местоположения). Вы моделируете электронные таблицы с предварительно заданными Row_Ids, содержащими данные. Вы должны нормализовать данные, как данные.

Это привело к обнаруженной проблеме, но есть и другие проблемы.

Если вы моделируете данные, Идентификаторы будут ясными, а ограничения индекса и FK будут предотвращать это. Какие данные независимы; какие данные принадлежат (зависит от), какие другие данные; какие данные делают то, что для других данных, и основы этих действий.

Затем (основные проблемы были устранены) вы остаетесь с незначительными ограничениями для решения небольших областей.
В противном случае вы застряли с добавлением ограничений по всему месту, чтобы попробовать и получить то, что хотите, но никогда не попадаете туда. Вы знаете, что они вам нужны, поэтому вы ищете их.

Неправильное место. Нам нужно выполнить резервное копирование до (1).

Я ответил на ваш другой вопрос и включил ▶ Модель данных датчика ◀. Это не устраняет недостатки, которые вы идентифицируете здесь. Тем не менее, я только что увидел этот вопрос, я буду обновлять DM завтра и включать эти таблицы и столбцы.

▶ Ссылка на идентификатор IDEF1X ◀ для тех, кто не знаком со стандартом для моделирования реляционных баз данных.

Вопросы

Похоже, вам нужна ссылочная таблица для датчиков, элемент полки, чтобы удерживать UpperLimit и LowerLimit; а не повторять его для каждого местоположения. Или они установлены локально для каждого местоположения.
Подумайте о том, что Logger является SensorNo нолем.
Почему у датчиков нет RFID?
В каждом Location параметр Logger необязателен, это 1:: 0-1?,

Ответ 2

Почему бы не иметь:

Alert [Table]
- Id [PK]  
- SensorReadingId [FK]  
- LoggerReadingId [FK]

И затем вы заполняете либо SensorReadingId, либо LoggerReadingId. Я полагаю, что ваша структура является упрощенной, но часто представляет собой таблицу, в которой нет ничего, кроме того, что один PK является избыточным.