8
防范数据库中错误的空条目的设计和实践
程序的一部分从数据库中的许多表和列中获取数据进行处理。有些列可能是null，但是在当前处理上下文中这是一个错误。 从理论上讲，这不会发生，因此，如果这样做，则表明数据错误或代码中存在错误。错误具有不同的严重性，具体取决于哪个字段null。也就是说，对于某些字段，应停止处理并通知某人；对于其他字段，应允许该处理继续进行，而仅通知某人。 是否有任何好的架构或设计原则来处理稀有但可能的null条目？ 解决方案应该可以用Java来实现，但是我没有使用标记，因为我认为问题在某种程度上与语言无关。 我的一些想法： 使用NOT NULL 最简单的方法是在数据库中使用NOT NULL约束。 但是，如果原始数据插入比随后的处理步骤更重要，该怎么办？因此，如果插入内容将a null放入表中（由于错误或什至出于某些合理的原因），我不希望插入操作失败。假设程序的更多部分取决于插入的数据，但不取决于此特定列。因此，我宁愿冒险在当前处理步骤而不是插入步骤中出错。这就是为什么我不想使用NOT NULL约束的原因。 天真的取决于NullPointerException 我可以使用数据，就像我期望它始终存在一样（这确实应该如此），并在适当的级别上捕获生成的NPE（例如，以便停止当前条目的处理，而不是整个处理进度） ）。这是“快速失败”的原则，我经常喜欢它。如果这是一个错误，至少我会得到一个已记录的NPE。 但是后来我失去了区分各种丢失数据的能力。例如，对于某些丢失的数据，我可以将其省略，但是对于其他一些数据，应停止处理并通知管理员。 null在每次访问之前进行检查并引发自定义异常 自定义异常可以让我根据异常来决定正确的操作，因此这似乎是可行的方法。 但是，如果我忘记在某个地方检查该怎么办？然后，我还会使用从未有过或很少有期望的空检查（因此绝对不是业务逻辑流程的一部分）使我的代码混乱。 如果我选择这种方式，哪种模式最适合该方法？ 欢迎对我的方法提出任何想法和意见。还有任何更好的解决方案（模式，原理，代码或模型的更好体系结构等）。 编辑： 还有一个约束，因为我使用ORM进行从DB到持久性对象的映射，因此在该级别上执行null检查将不起作用（因为在null不会造成任何危害的部分中使用了相同的对象） 。我添加此内容是因为到目前为止提供的答案都提到了该选项。