FK可以设计为可空/可选吗？ [英] Can FK be nullable/optional by design?

问题描述

大家好！


一般声明：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？


提前谢谢

解决方案

" Andy" <是ne ******** @ hotmail.com>在消息中写道< news：ed ************************** @ posting.google。 com> ...

大家好！

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

现实生活：
商业规则说不是每个记录都有父母。它是作为子记录实现的，其FK为null。


空无聊。处理Null是丑陋的任何方式你看它。

它的工作原理，它更简单。
满足业务规则和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进行比较
示例：选择属于任何组的所有客户端


通过一次调整，GroupedClient可以是

客户和集团。否则，您可以随时使用视图将案例B转换为案例A，以方便特定程序。

摘要问：是否值得使用CaseB？

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

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

来处理。


-

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

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

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

ne ***** ***@hotmail.com （Andy）写道：

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

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

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

以避免孤儿。


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

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


-

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

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

取决于集团是什么以及如何它是用来...


例如，

是一个超级客户群？ - 个人客户可能是

超级客户的子公司？

是内部指定的集团，如销售区域？


有多少客户可能没有团体？

当你需要对分组的客户采取行动时，你还需要

行为在没有分组的客户端上？


[ps。在案例B中，PersonID来自哪里？是客户端吗？]

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

案例A.
组（GroupID PK，名称，代码。）
客户端（ClientID PK，名称，GroupID FK NULL）

案例B（更清洁）
组（GroupID PK，Name，GroupCode。）

客户端（ClientID PK，名称，..）
子类型：
GroupedClient（PersonID PK / FK，GroupID FK NOT NULL）

在案例B中还有一个实体，与caseA 连接示例：选择属于任何组的所有客户端

摘要问：是否值得使用CaseB？

提前感谢

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

解决方案

"Andy" <ne********@hotmail.com> wrote in message <news:ed**************************@posting.google. com>...

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.
Nulls suck. Dealing with Null is ugly any way you look at it.
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)
In this scheme, a client may belong to no group or one group but
cannot belong to more than one group. Is this the business rule?
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
With one tweak, GroupedClient can be a many<->many link between
Client and Group. Otherwise, you can always use a view to turn
Case B into Case A for the convenience of a particular program.
Summary Q: Is it worth to go with CaseB?

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!

ne********@hotmail.com (Andy) writes:

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

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.

depends on what a Group is and how it is used...

e.g.,
is a Group a Super-Client? -- individual Clients may be subsidiaries of a
Super-Client?
is a Group in internal designation, like a Sales territory?

How many Clients are there likely to be w/o a group?
When you need to act on the clients that are grouped, do you also need to
act on the clients that are not grouped?

[ps. in Case B, where did PersonID come from? Is that the Client?]

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

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