这是 NULL 外键的有效使用吗？

Question

考虑我的架构的这个非常小的人为子集：

SensorType1
ID : PK

SensorType2
ID : PK

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

一些读数针对 SensorType1，一些读数针对 SensorType2。我可能会添加一个约束来确保这些 FK 中的一个始终指向某个地方。

我过去读过很多关于 NULL FK 的设计非常糟糕的文章，但我已经花了好几天时间研究我的模式（请参阅以前的帖子），无论我以哪种方式扭转它，我最终都会得到一个某个地方可以为 NULL FK，或者我必须为我拥有的每个传感器类型复制我的读取表（及其依赖项）（3）。

上述似乎很好地解决了问题，但出于某种原因，它在我嘴里留下了不太好的味道。这是我的整个架构中允许 NULL 字段的一处。

我认为一些同行评审会帮助我在继续之前接受它。

谢谢！

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”，这意味着他们必须在整个模型中不断更改名称。这使得遵循 RI 变得困难。我认识一些这样的人。我讨厌它，因为它阻止了自动查找列的方法。

我做这样的事情

SELECT * FROM ALL_TAB_COLUMNS WHERE Column_Name = :1;

如果你需要“角色扮演”在一个表中两次有相同的FK，那么

LIKE '%' || :1 should work.

但是你会改变列名称，即使不是被迫的。 ID 变为 Location_ID，然后变为 LoggingLocation_ID，没有技术原因，

我假设这不是物理模型。如果是，为什么要垂直划分 LiveMonitoringLocation 和 HandProbingLocation？仅仅是为了避免可以为空的列吗？如果是这样，你的效用函数就一团糟了。可空列很好...添加一个新表以避免可空列就像从纽约开车到克利夫兰再到波士顿以避免任何红灯一样。