Это допустимое использование внешних ключей NULL?

Question

Рассмотрим это очень маленькое надуманное подмножество моей схемы:

SensorType1
ID : PK

SensorType2
ID : PK

Reading
Timestamp
Value
SensorType1_ID FK -> SensorType1
SensorType2_ID FK -> SensorType2

Некоторые показания для SensorType1, некоторые для SensorType2. Я, вероятно, добавил бы ограничение, чтобы гарантировать, что один из тех FK всегда указывает куда-то.

В прошлом я много читал о том, что NULL FK является очень плохим дизайном, но я боролся со своей схемой в течение нескольких дней (см. Предыдущие посты), и независимо от того, каким образом я крутил и поворачивал ее, я либо заканчивал где-то с FK, поддерживающим NULL, или мне приходится дублировать мою таблицу считывания (и ее зависимости) для каждого типа датчика (3).

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

Я думал, что небольшая рецензия поможет мне принять это, прежде чем я продолжу.

Спасибо!

Answer 1

Что не так с этим делать, как:

Sensor
  ID: PK
  ... common sensor fields ...

SensorType1
  ID: FK(Sensor)
  ... specifics ...

SensorType2
  ID: FK(Sensor)
  ... specifics ...

Reading
  ID: PK
  Sensor: FK(Sensor)
  Timestamp: DateTime
  Value: whatever

Answer 2

Первые PK как просто «ID» означают, что они должны постоянно менять имена по всей модели.Это затрудняет следование за РИ.Я знаю таких людей.Я ненавижу это, потому что это мешает автоматическому подходу к поиску столбцов.

Я делаю что-то вроде этого

SELECT * FROM ALL_TAB_COLUMNS WHERE Column_Name = :1;

Если вам нужна «ролевая игра», один и тот же FK дважды в таблице

LIKE '%' || :1 should work.

Но вы меняете имена столбцов, даже если вас это не заставляет.Идентификатор становится Location_ID, а затем становится LoggingLocation_ID без технической причины

Я предполагаю, что это не физическая модель.Если это так, почему вы вертикально разделяете LiveMonitoringLocation и HandProbingLocation?Это просто чтобы избежать обнуляемого столбца?Если это так, то ваша служебная функция все испортила.С столбцами Nullable все в порядке ... добавление новой таблицы, чтобы избежать столбцов Nullable, похоже на поездку из Нью-Йорка в Кливленд в Бостон, чтобы избежать каких-либо красных огней.