数据库 SQL 约束之 UNIQUE

嘿，老铁们，今天咱们聊聊数据库里头挺有意思的东西——UNIQUE约束。
说实话，这玩意儿用好了，数据质量立马能上个台阶。

我之前在一家搞电商的搞系统的时候，遇到过这么个坑。
有张表存用户地址的，本来以为搞个自增ID当主键就万事大吉了。
结果呢？用户可以填同一个地址，比如“北京市朝阳区望京SOHO”这种大热地址，结果数据库里头就可能出现两条记录地址完全一样，但ID不一样。
这事儿要是不管，后续查数据的时候简直要疯，用户投诉电话能被打爆。

所以我就琢磨，这得加个UNIQUE约束。
说白了，就是在建表的时候，指定某个字段或者某几列组合，必须得独一无二。
比如，在地址表里，我直接在address字段后面加一句UNIQUE。
建表语句大概是这样：
sql CREATE TABLE user_addresses ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, address VARCHAR(2 5 5 ) NOT NULL UNIQUE, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );
你看，这里address字段后面加了UNIQUE，现在再往里插数据，如果地址字段有重复，数据库直接就拒绝：
sql INSERT INTO user_addresses (user_id, address) VALUES (1 , '北京市朝阳区望京SOHO'); -
这条能成功
INSERT INTO user_addresses (user_id, address) VALUES (2 , '北京市朝阳区望京SOHO'); -
这条会失败，报错说违反了UNIQUE约束
有意思的是，有时候光靠一个字段还不够。
比如我们搞个“昵称+用户ID”的组合唯一性，防止不同用户用相同昵称。
这时候就得用多列UNIQUE。
建表时可以这样：
sql CREATE TABLE user_nicks ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, nick VARCHAR(5 0) NOT NULL UNIQUE );
现在，user_id和nick组合必须唯一。
假设用户A叫“阿常”，用户B也叫“阿常”，数据库会自动区分，因为他们的user_id肯定不一样。

当然，表都建好了，临时想加个约束也没毛病。
比如发现之前建的订单表没加金额的唯一性，现在想加。
这时候就用ALTER TABLE：
sql ALTER TABLE orders ADD CONSTRAINT unique_order_amount UNIQUE (amount);
这条命令会在orders表上添加一个名为unique_order_amount的UNIQUE约束，作用在amount字段上。

要是以后发现这约束是个坑，比如业务变了，允许金额重复了，也能删。
删的方式也是ALTER TABLE：
sql ALTER TABLE orders DROP CONSTRAINT unique_order_amount;
说实话，UNIQUE约束用起来挺顺手的，但关键在于设计阶段得想明白。
有时候业务人员觉得“多个字段组合唯一就行”，结果开发按字面意思加了，测试一查发现“这个组合根本不可能重复”。
这种时候，测试小哥的头发可能要掉不少。

我这块脑子记得，以前有个项目用UNIQUE约束导致性能问题。
那会儿表数据量不大，但某个UNIQUE字段特别常被用来做查询条件。
结果某个高峰期，数据库CPU直接飙升。
后来查了半天，发现是UNIQUE索引惹的祸。
这事儿提醒我，加约束不能只看“功能对不对”，还得考虑“性能行不行”。

数据记得是X左右，但建议你核实下，不同数据库系统对UNIQUE约束的处理可能有点细微差别。
比如MySQL和PostgreSQL在处理重复插入时的错误消息就不太一样。

总之，UNIQUE约束是个好东西，用好了能省不少后劲。
但具体怎么用，还得结合实际业务场景来定。
别像我之前那样，光顾着加约束，忘了看性能影响。

数据库外键约束是什么？外键的作用、创建及使用详解

外键约束保证数据一致。

父表删除，子表引用不删。

创建表时加外键。

已存在表用ALTER TABLE加。

ON DELETE CASCADE自动删除子表关联。

ON DELETE RESTRICT阻止删除。

建索引提高外键查找速度。

别搞循环引用。

批量操作可临时禁用外键。

起名规范，方便管理。

应用层控制不如数据库层可靠。

你自己掂量。

access数据库如何设置约束？

嘿，咱们聊聊数据库那点事儿。
以前在论坛上看到不少新手，对数据库里的access约束这事儿挺迷糊的，我就得耐着性子解释一番。

说实话，数据库的access约束就像是给数据穿上了“规矩”的外衣。
咱们举个例子，就像咱们国家交通规则，规定了车辆怎么走，这保证了路上的秩序。
数据库里的access约束，也是为了确保数据这个“交通”有序进行。

首先，得说说字段属性设置，这就像是给每个数据“车辆”规定了行驶的“车道”。
比如，咱们有个“员工”表，里面有个“年龄”字段，规定它只能存放数字，这就限制了只能放年龄这个“车辆”，别的“车辆”（比如文字）就上不去这个“车道”。

再来聊聊主键约束，这就像是给每个“车辆”配了个独一无二的牌照。
比如“员工ID”，它得是独一无二的，不能有重复，这样就能保证每个员工都能被唯一识别。

然后是外键约束，这就像是规定了“车辆”得在规定的路线上行驶。
比如，“员工”表里的“部门ID”是外键，它必须对应“部门”表里的某个“部门ID”，这样就能保证员工所在的部门是存在的。

唯一性约束，就像是在某些关键路口设置了单行道，只能走一次。
比如，某个“姓名”字段设置了唯一性约束，那就不允许有两个人同名。

检查约束，这就像是给“车辆”设置了速度限制，比如“年龄”字段设置了检查约束，只能输入0到1 5 0之间的数字。

至于触发器和存储过程，这就像是交通警察，当“车辆”违反规则时，它们会自动介入。
在Access里，虽然不像某些数据库那么强大，但我们可以用VBA来写这些“警察”，确保数据的准确性。

我记得有一次，有个新手问我在Access里怎么设置年龄的检查约束，我当时也没想明白，就查了查资料，才知道可能需要用VBA或者数据宏来实现。
这块儿，数据我记得是X左右，但建议你核实一下。

总的来说，设置这些access约束，就像是给数据库的交通规则加了码，保证了数据的准确性和一致性，减少了数据错误和不一致的问题。
这就像是在论坛里答疑解惑，虽然有时候解释起来有点绕，但看到新手们理解了，心里还是挺美滋滋的。