数据库面对不同业务逻辑约束条件的选择

数据表的约束我觉得还是很有用的，至少在数据库优化方面还是用的比较多的，可以大大的提高检索效率，作用也是比较明显的，另外一点，表的约束可以在某种程度上简化程序代码端的业务逻辑量，这寄存于DBMS上面，其维护性我绝得韩式比较高的，这一般类型的数据库里面，我们常见的约束有：主键，外键，为空，唯一等，这四类是比较常见的约束，我绝对约束的实质应该是为真实的业务逻辑而服务的，否则则没有意义，所以，面对不同的业务逻辑逐一的进行分析：
1:什么情况下使用主键：
主键的含义是唯一且不为空，所以根据这个规范，能够满足的业务逻辑有很多的，列如我们常见的ID值，必须存在而且不存在为空的情况，一般来说一个表的会有一个主键，至少方面以后的操作，因为无论无论dql语句还是dml语句都得需要唯一不为空的标识符当做索引值，而且，无特殊的逻辑要求，会要求主键自增张：auto_increment;这样也是符合一般的逻辑要求的，还可以提高检索速度。
2：什么情况下使用外键：
表的外键其实就是主表对于本表的一个约束，说白了就是就是在外键字段要求的范围内，表示的是一个主从关系，例如部门表和员工表的关系。部门表是一个主表，有一个主键值，那么如果员工表想要和主表建立主从关系就要建立一个外键，这里必须明白一个地方，什么所谓的建立外键都在建立在从表里面的，主表和普通的操作没有任何区别，在从表建立的外键就是一个指定主表主键的关系，这样的话就构成了一个约束关系，比如说一个员工属于哪一个部门的关系这样距可以确立了，当然还要注意的是，外键不一定是指向主表的主键，还可能是unique值，就是外键唯一，当然符合业务逻辑，还有外键值也是可以为空的，至于这要一开始我也是不理解的，既然建立了外键确立了约束条件那为什么还可以为空，但是我又结合实际的业务逻辑想一下，如果一个新员工没有确定部门但需要加入数据库那怎么办，所以外键为空值就符合一般的业务逻辑了。
3：什么情况下使用不为空not null
这个的意思就非常的好理解了，就不多做介绍，但是业务逻辑还是有必要说一下，以前这个约束条件我用的就不是很合理，不管什么我都是不为空，虽然效率高了，但是这是非常的不科学的，比如所一个注册表会有很多信息，什么为空什么不为空都得要根据实际的业务逻辑想一下，需要这么想一下，首先应该要根据业务需求来选择，如用户名，密码，邮箱，年龄，生日，身份证号这几个注册表字段信息，首先用户名，密码，邮箱（一般来说登录或者找回密码用到）是必不可少的，所以是一定不能为空的，而年龄和生日在一般的无特殊需求的情况下是可以不填写的，如果设置了不为空，那么非得强迫用户填写吗，还有就是身份证号码，这个其实不太恰当，身份证号作为用户比较隐私的东西，如果说网站需必须要要身份号这样信息时可以不为空，反之可以为空，默认即可。
4：什么情况下使用unique：
这个约束的意义是唯一但可以为空，为空是和主键唯一的区别，这个约束相对来说还是比较有用的，如部门的名字，当然是唯一的，但是有的新部门没有名字也是可以为空的，但是有的时候肯定会有这样的需求，一个表想要多个主键，这是可以用unique结合not null代替一下，毕竟unique可以用多个的，然而如果你还想为唯一性指明条件的话也是可以的，这也是允许的。

综上总结：所有的约束条件的建立都应该根据业务实际需求而建立