check约束表达式怎么写

上周正在查看数据库文档。
验证限制非常重要。

定义规则。
确保数据满足条件。

写入方法-ALTER TABLE。

例如，添加约束。

后跟约束的名称。
建议以CK_开头。

然后CHECK（布尔表达式）。

对布尔表达式使用 TRUE/FALSE。

1 .简单条件
年龄不能为负数。

检查（年龄 >= 0）。

工资从3 000到1 0万。

检查（工资从3 ,000到1 00,000）。

2 多重值限制
性别只能是男性或女性。

检查（性别IN（“男”，“女”））。

订单状态限制。

检查（状态输入（“等待”、“已发送”、“已交付”））。

3 逻辑复杂
折扣范围为0到1
CHECK(折扣>=0 AND折扣<=1 )。

简单地检查电子邮件格式。

检查（电子邮件如“%@%.%”）。

4 注意事项
性能必须优秀。

不要使用复杂的表达式。
验证会很慢。

分离限制更好。

数据类型必须匹配。

例如，年龄字段不能包含字符串。

测试很重要。

插入无效数据看是否报错。

还检查更新的数据。

字段之间的限制是可以的。

例如，结束日期必须晚于开始日期。

注意数据库兼容性。

某些数据库不支持此功能。
也许使用触发器。

创建表时可以直接添加限制。

例如：
CREATE TABLE Students...
CHECK（分数 0 TO 1 00）...
您还可以添加限制。

ALTER TABLE 学生...
ADD CONSTRAINT CK_Name...
CHECK(LEN(name) >= 2 )...
总之，Check 约束非常容易使用。

保证数据完整性。

sql 中 check 约束用法_sql 中 check 约束限制数据范围详解

说实话，当我第一次接触数据库时，我对检查约束感到困惑。
我记得当我第一次在项目中使用它时，MySQL居然忽略了它，这让我很困惑。

你看，用CHECK(age>0 andage=1 5 0)来限制age这样的字段，真是太实用了。
我之前有一个项目，用户数据存储在表中，我直接添加了这个约束。
后来发现有人填了2 00岁的表格，系统自动报错。
说实话，还有很多麻烦。
这种类型的数值范围限制在电子商务系统中尤其常见。
例如，该值必须大于 0，并且该项必须为非负数。
这些都是直接使用CHECK约束来解决的，简单明了。

有趣的是，检查计数器值也很常用。
例如，性别字段使用值“男”、“女”和“其他”。
我有一个医疗系统，其中患者的性别仅由这些数字填写。
再多一个就不行了。
我可以使用 check(gender IN('male','female','other')) ，而不需要在代码中写判断。
这比应用层的硬编码更可靠。
毕竟，开发人员总是有可能因滑点而犯错误。

字符串长度限制非常实用。
我记得有一个论坛系统，用户名应该大于3 个字符且小于5 0个字符，所以只需使用CHECK(LENGTH(username)>=3 )来解决问题。
这比在应用层重复拦截字符串要容易得多。

但是，判断多领域联盟时应特别谨慎。
之前接手一个老项目，有一份订单上面写着“如果有条件发货，收货日期必须小于或等于当前日期”。
如果写成 CHECK (of ShipDate<=CURRENT_DATE)，则结束。
如果数据不一致，此阈值将报告错误，因为更新状态和更新接收日期可能不在同一事务中。
我当时不知道该怎么办，所以我转而使用触发器来检查。
因此，连接多个字段时，必须考虑数据变化的顺序。

我在使用 MySQL 时遇到了很多麻烦。
有一个项目使用了支票（Salary>Bonus），但结果证明不起作用。
MySQL查了好久据我了解，默认情况下它不强制执行 CHECK 约束。
后来我们改用触发器或者应用层做双重认证，就可以执行了。
MySQL数据库的特性给我留下了特别深刻的印象。

不同数据库的支持差异也很有趣。
PostgreSQL 和 SQL Server 严格执行检查约束，一旦定义就会生效。
但MySQL很困惑。
尽管支持语法，但默认情况下根本不实现它。
这使得在迁移到数据库缓冲区时需要将检查约束转换为触发器或应用层验证，这是非常烦人的。
命名也非常重要。
如果不添加强制名称，系统默认生成的名称将会很混乱，您将不得不猜测是否要更改约束。
我通常会给约束一个不言自明的名称，例如 ALTERTABLE ORDERS ADD CONSTRAINT CHK_ShipDate validate(ShipDate<=CURRENT_DATE)，因此当我展望 SQL 语句或数据库模式时，我一眼就知道它的作用。

数据复杂时，不要写太复杂的检查条件。
在我有一个表之前，我想限制“如果产品类别是A，则价格必须大于1 00”，我将其写为检查（如果产品类别是“A”，则价格> 1 00，否则为真结束）。
结果这个SQL运行了很久就报错了。
后来，有两个检查约束，一个检查重写为(Product Category = 'A' AND Price >=1 00)，另一个检查重写为(Product Category 'A' AND Price >=0)，然后通过。
你说这种复杂的表达不仅会影响性能，而且会让后来接手的人看不懂。

一般来说，检查约束是个好东西，但是使用时应该考虑数据库的特性。
特别要注意的是，MySQL 用户默认情况下不强制执行约束。
其他数据库如PostgreSQL等都可以直接使用，省去了很多麻烦。