前言：

今天有点累可能平时睡的比较晚导致今天白天状态不佳，一直瞌睡了，嗯，不管怎样今天总感觉应该写点啥，还是写写吧；以下内容全是看了一些资料请教一些行内朋友得到一些结论，无论对错希望看到这篇日志的同行们给一些宝贵的建议，也可以QQ给我私聊，但不要转载了，毕竟这是原创~

这两天一直在和行业内的朋友探讨项目中是否对业务表创建外键关联的问题，这个问题其实有值得探讨的东西；有些同行们会发现有些公司有些项目开发过程中基本上没有遇到过主外键关联或者公司技术老大或者项目经理建议不使用主外键关联约束，这其实都是有自己的考虑的，站在他们的立场也是可以理解的，不能直接否定不使用主外键就是错的；无论是DB2，mysql，oracle都给我们提供了主键，外键功能；大多数情况下如果按照数据库3范式的要求任何一个表里都要有个主键作为记录的唯一标示，这个好理解； 外键是否真的有必要呢，有哪些优缺点呢？我们开始分析：


一、表主外键使用

外键的优点：

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


外键的缺点：

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


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

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


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

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


个人心得：

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



二、表操作技巧心得

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



以上内容也是自己的一些拙见，分享一下，欢迎大家对此内容进行探讨同时多提一些建议，谢谢！