我正在为数据库编写代码。我有一个包含机器活动日志的表，看起来像：
CREATE TABLE Work(
id SERIAL PRIMARY KEY,
machine_ID integer NOT NULL DEFAULT 0,
start_work timestamp,
etc...
);
我知道machine_ID可以在1到5之间。
我的问题来了：
使用CHECK(machine_ID >= 1 AND machine_ID <=5)有什么好处吗？
接受污染数据以便以后修复可能的错误，甚至使用清理数据的可能性不是更好吗？
答案 0 :(得分：1)
或许这更适合作为评论。
但是，不应使用machine_id约束来验证名为check的列。相反，你应该有一个表 - 比如machines - 这是机器的参考表。
您的代码应使用foreign key约束。这是一种特殊类型的数据验证，称为关系完整性。
至于你的问题。根据我的经验，通常在进入数据库时捕获错误会更好。数据库中的错误数据通常会导致问题进一步发展 - 本来可以避免的问题。
答案 1 :(得分：0)
如果你想限制你的数据库中id的数量，那就太好了。
答案 2 :(得分：0)
这是一种主观的，具有不同的方法和观点，并且高度依赖于您的商业案例。
一个原则是保持简单，但即使 意味着什么也是主观的。
拒绝提前
在预处理层中，将规则应用于正在接收的数据。尽快拒绝任何行/文件/来源并请求重新提交。
这清楚地说明了已接受的内容，未被接受的内容，如何处理此类情景等。
消费一切
如果故障可能复杂多变，数据库往往是进行分析以了解故障的来源，原因，程度和/或影响的最佳位置。在这种情况下，摄取一切都是有益的。
但这可能会产生潜在的无法控制的影响。因此，我对此的一般体验是在数据库中有一个单独的暂存区域。基本上尽可能不结构化，允许尽可能多的数据。但即使这并不总是有帮助的。如果对所有字段使用字符串，则可以接受通常必须接受的数据。但即使这样，如果你有一个包含9列的文件为8列表提供了怎么办？你可以将整行作为一个单独的字符串接受，但是分析它以获得有意义的结果几乎是不可能的。
在您的情况下，这意味着取决于您正在处理的项目，这就是您未描述的内容。
我的个人默认位置是将某些源数据故障重新分类为预测/一切照旧的不一致。然后，您可以构建临时区域来处理这些区域，用于报告，协调，补救措施等。更重要的是，明确地将它们构建到所有相关的业务流程中。这样做会引入一个成本，可以根据容纳它们的好处进行估算，目的只是在实际上是物质利益的情况下容纳不一致。 （而不仅仅是保持一切的囤积者，以防万一有一天它可能会帮助某人。）
然而，无论采用何种方向，操作数据库本身（不是暂存区域）都是结构严重的，其中存在完整性约束，以防止错误，意外输入等破坏现有数据或导致意外的，不受监控的后果。< / p>
如果你真的相信你的操作数据库（那是事务性的，分析性的或其他任何东西）会因缺少一些/多个/所有这些数据完整性工具而受益，那么SQL关系数据库对你来说可能是错误的工具。而是考虑大量非结构化数据存储和处理平台。
答案 3 :(得分：-1)
有许多不同的考虑因素。
首先，我不希望对可能发生变化的业务规则使用检查约束 - 我不想推出数据库模式更改（并且检查约束是模式更改）以响应可预测的商业活动。添加或删除机器感觉就像一个可预测的业务事件;正如@gordonLinoff建议的那样，我建议在机器上使用外键＆＃34;表
其次，我不喜欢＆＃34;隐藏代码＆＃34; - 从开发和维护的角度来看，我希望尽可能保持所有验证的可理解性。检查约束和触发器相对“隐藏”，难以记录，难以调试，难以测试非平凡的用例;另一方面，外键是明确的，开发人员期望它们。