mysql - 数据库设计: FKs that are NULL - good or bad?

Question

假设我有一个“消息”表，其中我想存储我的应用程序支持的所有可能的消息。例如，在类似 FB 的应用程序中，可能有“媒体消息”(例如照片、视频、音频)、“媒体相册消息”、“私有(private)消息”等。对此进行建模的一种方法是:

Table: message
- messag_id (PK)
- user_id (FK, this is the sender of the message)
- message

TABLE: media_message
- media_message_id (PK, receiver of the message implied by the owner of the media)
- message_id (FK)

TABLE: media_album_message
- media_album_message_id (PK, receiver of the message implied by the owner of the media album)
- message_id (FK)

TABLE: private_message
- private_message_id (PK)
- message_id (FK)
- user_id (FK, receiver of the message)

... etc.

因此，对于每种“类型”的消息，我需要创建某种“映射表”。

像这样的东西会起作用吗:

TABLE: message
- message_id (PK)
- receiver_user_id (FK)
- sender_user_id (FK) 
- message
- media_album_id (FK, NULL allowed)
- media_id (FK, NULL allowed)

我认为通过这种设计，我仍然可以强制引用完整性。如果 media_album_id 和 media_id 都是 NULL，那么我可以假设它是“私有(private)”消息(或在应用程序层实现一些类似的逻辑)。缺点，如果它甚至是缺点的话，那就是总会有未使用的列。话又说回来，也许这会更好地扩展——更少的 JOIN 等。

想法？

Answer 1

不好。避免可以为空的“外键”。它们有很多缺点。

当外键包含空值时，并不总是强制执行对引用行的约束。但是，不同 DBMS 之间的默认行为并不一致。有些 DBMS 支持配置选项来更改可为空外键的行为，有些则不支持。因此，从数据完整性的角度来看，SQL 开发人员和用户可能不清楚可为空的外键约束实际上意味着什么。在 DBMS 产品之间甚至在使用同一产品的不同服务器之间移植数据库可能会产生不一致的结果。

数据库设计工具、集成工具和其他软件并不总是正确支持它们，并且它们产生的结果可能是错误的。

外键经常用在连接和其他查询逻辑中，对于那些认为约束有效但实际并不有效的用户来说，问题更加复杂。

从逻辑角度来说，可为空的“外键”约束没有多大逻辑意义。根据 SQL 标准，即使引用的表为空，也不会违反此类约束。这与使用 null 的最常见的所谓理由之一相矛盾 - 它代表“未知”的情况。如果 X 没有有效值，那么任何“未知”X 肯定不能是有效值 - 但 SQL 会允许它!

最后，这是没有必要的。您始终可以构建表，这样就不需要空值。因此，为了简单性和准确性，最好将空值排除在外，而不是放入空值。