定义域时何时应添加非空约束？答案

【问题标题】：When should we add not null constraint when defining a domain?定义域时何时应添加非空约束？
【发布时间】：2017-02-08 19:03:01
【问题描述】：

在设计一个新的领域类时，我常常陷入两难的境地。当我在 Grails 中创建一个新的域类时，我几乎没有属性。我可以在这些属性上添加非空约束或使它们可以为空。在我创建的域中的许多情况下，这种选择似乎是可选的。那么，添加不可为空约束和非空白约束的一些充分理由是什么？我需要几点来理解什么时候应该关心这些约束。谢谢！

static constraints = {

        title nullable:true, blank:true

    }

【问题讨论】：

标签： grails

【解决方案1】：

您应该考虑一下您的模型...拿一个小部件。构成 Widget 的必要属性有哪些？也许它只是一个名称或零件号，而所有其他属性都是不错的或额外的细节。也许它的名称和零件号。必要的属性将收到 nullable:false。任何其他都可以为空：true。

空白，是真是假？好吧，我认为空白字符串作为值没有太多实用性。我宁愿处理更简单的情况或 null 而不是 null 来指示是否存在数据。

【讨论】：

谢谢！这有助于我的理解。
想一个小部件的类比，让我们拿一个闹钟。对于这个小部件，我假设不可为空的属性可以是重量、颜色、防水、数字等，并且可以为空的属性可以是所有者。对吗？
回到建模问题。重量、颜色等取决于什么是必要的，或者不错的，或者与您的系统无关。如果您正在模拟物理现实，那么您提到的所有属性 nullable:false（可能还有更多）可能都是正确的，包括所有者为 nullable:true。如果你的系统有一个更简单的闹钟定义，那么那些可以为空的标志可能会改变。

【解决方案2】：

nullable 表示该属性可能没有价值。这也是 (SQL) 数据库建模的方式 - 所以这个设置最终会出现在你的 (SQL) 数据库的表约束中（例如NOT NULL）。

（SQL）数据库也可以查询：is null 和 is not null。这可能会导致一些令人惊讶的结果（例如，有顺序）。

成为nullable 使得例如布尔三态。它可以是 true、false 或 null - 所以 /yes/、/no/ 或 /no decision made/（或撤销）。

使用 GORM 对数据库建模时，nullable 的常见位置是 0..1 关联。

或者简而言之：想想Optional 或Maybe。

【讨论】：

所以布尔值通常不能为空。对吗？
我不会这么说的。例如。如果您在系统中添加一个新标志（功能开/关），您可以将其保留为空，以表示“没有人决定支持或反对该功能”。即使没有价值，它也拥有信息。

【解决方案3】：

场景，

我们添加constraint :- nullable :false, blank:false

属性是identity的手段
属性正在添加value(importance)
属性将在reducing query complexity 中提供帮助
属性不能是null 或blank 只是因为业务逻辑。

【讨论】：