数据库主外键

一、表主外键使用

外键的优点：

保证数据的完整性，当删除主表关联数据时如果存在子表关联数据时数据库会提示操作错误，当然这个可以在创建主外键关联关系时指定同步删除的操作，这样当删除主表数据时所关联的子表数据也会同步删除；
这样利用数据库提供的主外键功能就能最大限度的保证数据的完整性，数据库端控制往往也是数据验证的最后一个关卡；


外键的缺点：

1，业务数据绑定了，失去了数据操作灵活性；
2，使用外键时如果不给外键创建索引容易出现死锁的情况；
3，数据插入、修改、删除、查询会有性能的影响；
4，数据迁移的时候也会遇到问题；
5，当数据库中关联关系过于复杂增加维护成本；
6，给大表做表分区时外键不可取（如果分区表很多，不可能对多个分区表都创建主外键关联关系）；
7，集群状态下，主外键关联关系可能不适用 （待讨论和验证）


为什么系统会存在主键外键关联关系？

系统存在主外键关联关系是为了保证数据的完整性；


在实际项目的数据库中是否使用主外键？

无论大牛和小牛们怎么说，无论是答案是肯定和否定，我们都应该要看实际的项目情况和技术场景去分析，如果系统对数据要求的十分的苛刻像银行系统那样，这种情况下可以牺牲一些主键带来的性能影响最大限度的保证数据的完整性；像web互联网一类的项目如果性能响应要求的十分苛刻，而且互联网数据量较大会使用数据库集群和大表分区等技术，因此这种情况下不建议使用主外键关联，在不使用主外键的情况下一般大都会把数据完整的维护交给了系统中的业务模块来维护，但这对程序的代码质量要求非常高；(此段内容仅针对关系型数据库，noSQL的应用项目除外)；


个人心得：

无论什么系统只要是基于关系型书库的软件系统都不能100%的保证不使用任何的主外键关联；对于大多数系统而言其权限模块应该是考虑使用主外键的最佳场景；对于关键性业务的数据应该考虑使用主外键来保证数据的完整性，对于其他大多数次要业务可以不使用主外键约束而是用系统对应的业务模块来维护；
前期设计，开发，测试，试运行时我们可以尝试着给系统业务关联表创建主外键关联关系，这样可以从数据库底层制约我们的程序代码（假如误删主数据，数据会提示存在字表关联数据，不能执行操作类的提示，可以利用主外键关联关系验证业务代码流程是否存在BUG），等系统运行?正常了删除不必要的主外键关联；（此段内容可能存在歧义，可以一起学习和交流）；



二、表操作技巧心得

平时我们会对系统做一些数据验证，例如字段非空，长度，默认值，数据类型，唯一性；对于这些数据内容我们可以利用HTML标签的属性来约束，另外我们在创建数据表时应该尽量的做好分析，例如，在写创建表脚本时指定字段的类型，默认值，长度，非空，唯一约束等，从数据库端对数据进行拦截，从而保证了数据的有效性，也能提高我们的开发速度和代码质量（因为当INSERT SQL写的不满足表结构规则时会数据库会提示错误，这样可以让我们快速的定位问题）；