考虑我的架构中这个非常小的设计子集：
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字段。
在我继续前进之前，我认为一些同行评审会帮助我接受它。
谢谢！
答案 0 :(得分：2)
这样做有什么问题：
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
答案 1 :(得分：0)
首先PK只是“ID”意味着他们必须在整个模型中不断更改名称。它使RI跟随困难。我知道有些人喜欢这样。我讨厌它，因为它阻止了自动查找列的方法。
我做这样的事情
SELECT * FROM ALL_TAB_COLUMNS WHERE Column_Name = :1;
如果你需要“角色扮演”在表中有两次相同的FK，那么
LIKE '%' || :1 should work.
但即使不被强迫，你也会改变名称。 ID变为Location_ID，然后由于技术原因变为LoggingLocation_ID
我假设这不是物理模型。如果是，为什么要垂直分区LiveMonitoringLocation和HandProbingLocation？是否只是为了避免可以为空的列？如果是这样，你的实用功能就搞砸了。可以为空的列很好...添加一个新的表以避免可空的列就像从纽约市开往克利夫兰到波士顿，以避免任何红灯。