FK可以设计为可空/可选吗？

问题描述

大家好！


一般声明：FK不应该是nullabe以避免DB中的孤儿。


现实生活：

业务规则说不是每条记录都有父母。它是实现的，因为子记录的FK为空。


它有效，而且更简单。

满足业务规则且FK不为null的设计可以实现
但是会更复杂。


示例：有客户端。客户可能只属于一个组。


案例A.

组（GroupID PK，名称，代码？）

客户端（ClientID PK，名称，GroupID FK NULL）

案例B（更清洁）

组（GroupID PK，名称，GroupCode？）

>
客户端（ClientID PK，名称，？。）

子类型：

GroupedClient（PersonID PK / FK，GroupID FK NOT NULL）


案例B中还有一个实体，与caseA相比需要额外的

加入

示例：选择属于的所有客户端任何团体

总结问：是否值得去CaseB？


提前谢谢

解决方案

案例C.使用一个或多个特殊组包含包含否则

" groupless"客户端。但是，您现在拥有特殊功能。团体

来处理。


-

Joe Foster< mailto：jlfoster％40znet.com>签收支票！ < http://www.xenu.net/>

警告：我不能对上述事项负责因为我的猫已经来了

显然学会了打字。把我带走，哈哈！

我不明白这句话背后的原因。

引用另一个表的键的任何列应明确指定为

以避免孤儿。


如果该列可能有时是未知/未指定完全有效的

记录，我认为没有理由不让它可以为空。


-

尽管热烈争论专利保护对于软件行业的发展至关重要，但评论员们已经注意到，如果没有专利保护，这个行业将实现跨越式发展。 ''"

- 美国最高法院大法官约翰保罗史蒂文斯，1981年3月3日。

Hi All!

General statement: FK should not be nullabe to avoid orphans in DB.

Real life:
Business rule says that not every record will have a parent. It is
implemented as a child record has FK that is null.

It works, and it is simpler.
The design that satisfy business rule and FK not null can be
implemented but it will be more complicated.

Example: There are clients. A client might belong to only one group.

Case A.
Group(GroupID PK, Name,Code?)
Client(ClientID PK, Name, GroupID FK NULL)
Case B(more cleaner)
Group(GroupID PK, Name, GroupCode?)

Client (ClientID PK, Name, ?.)
Subtype:
GroupedClient (PersonID PK/FK, GroupID FK NOT NULL)

There is one more entity in Case B and it will require an additional
join in compare with caseA
Example: Select all clients that belongs to any group
Summary Q: Is it worth to go with CaseB?

Thank you in advance

解决方案

Case C. Use one or more "special" groups to "contain" otherwise
"groupless" clients. However, you now have the "special" groups
to deal with.

--
Joe Foster <mailto:jlfoster%40znet.com> Sign the Check! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They''re coming to
because my cats have apparently learned to type. take me away, ha ha!

I don''t see the reasoning behind this statement. Any column that
references keys to another table should be explicitly specified as such
to avoid orphans.

If that column may sometimes be unknown/unspecified for perfectly valid
records, I see no reason not to make it nullable.

--
"Notwithstanding fervent argument that patent protection is essential
for the growth of the software industry, commentators have noted
that `this industry is growing by leaps and bounds without it.''"
-- US Supreme Court Justice John Paul Stevens, March 3, 1981.

这篇关于FK可以设计为可空/可选吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！