大概是两年前的样子，认识了一种思想，项目建表一般不用外键，一般不用外键是说得比较多的，没有说主键，和唯一约束，其实唯一约束我也很少看到有人在用,即使后期维护数据问题存在很大的麻烦，大家也原意或者是没有意识到而去花大量的时候去修复数据问题，去寻找问题的原因等等.
这一下都到14年4月下旬了，我之前开始写博客感受到了确实对自己，对别人都有帮助（即使文中有误的地方也可能引大家去思考，从中学到东西，本人有时就是大别人的错误中一次又一次的确认自己的理解是不是正确的，或者要去网上查找一些资料，我想总是有进步的），给自己定的小目标是至少一个月要更新一篇博客，之前也一直没有想到什么要更新的东西，平时也忙，也闲，说忙其实近阶段大事情挺多的，说不忙，平时回家还是要在忙中抽点时间来dota2一把，围棋也来个一两盘，说到国棋从今年开始对收官方面有了进步，以前都是虎头蛇尾，开头布局还可以，看到形势也不错，可到最后收官算下来还会输棋。围棋确实挺好的，像其它的游戏或者说爱好可能一段时间就淡了，但是这个我还是下了很久了，从大学一直到现在，偶尔会下两盘（这里推广一下围棋吧，国粹，从中能学到很多道理，有爱好者可以一起交流，我是初级皮毛级别）。好了费话不多说今天的主题，我是想说主键，外键等约束的重要性。
前面一段说到以前接受到一种思想是不要使用外键，这样的好处是什么？
1.这样给测试带来很大的麻烦，比如前期测试数据的添加，清楚等都不方便
2.用业务逻辑来控制有关联表的数据写入，删除。（这个难道也是第1点，不能让中间报错出来而自己控制）
3.（这个我写的时间都差点忘了）说这样插入数据的性能有所提高，当时特别强调的是大数据量的情况下千万不要用外键，因为他要在插入的时候去检测主键里否存在。
大概就是上面这些原因吧，当然这些也不是没有道理，现在做的很多项目是没有用外键，就是平时一个default约束都会搞得你在修改数据，修改表结构是很麻烦，所以我也是挺认同这些观点的。
最近几天吧，由于客户数据出现问题，出现了相同的单据编号，产品里面定义的是单据编号是不能相同，但是客户还是出现了相同的单据编号，并且每天都有几张单据，最后找出原因是由于并发的问题，也就是两个用户同时做一张单据，同时写入数据库。那有同学肯定会想，难道写入单据的时候没有验证单据编号是否相同吗？有，当然有验证。有用事务吗？有，当然有。先看下面代码
--1.检查是否有这个编号 --2.保存
上面一段代码是在一个事务中，这样大家觉得会出现相同的编号吗？事务的隔离级别是read committed或者 snap的read committed。
其实这里同事务关系不大，这里就不主要说事务了，上面这种情况下是存在重复的可能的，我们看一下示意代码
begin tran if exists(select 1 from tb where code=@code) -- 可以反回重复的信息 else insert into tb ... commit tran
这个很简单会出现重复的，两个事务同时开启，在验证的时间，两个都是没有重复的，在插入的时候两条数据就插入了。更有基者是在上层代码里面先调一个验证方法，然后再写入数据，这样肯定也是会出现重复的。这里我就是在这个表的编号不是不能重复吗？为什么不直接用一个unqiue来约束呢？当然在现实中，这个表是有设置为可以重复的编号的，但是如果一个表一开始就定了一列是不能重复的为什么我们不大胆的用unqiue约束呢？为什么不能用default()约束呢？这里也就说到了外键，为什么不能用外键约束呢？主键也是，可能用很多人用主键也是用一个索引的功能，基是主键也是约束，只是依附于索引上面。我就是在想用了这些约束后，前期可以测试，调试等都会更复杂，但是后面的数据问题（或者说更严重的问题）可能会更少。所以我还是认为要以大量的使用这些约束的。
当然，现在如果是做项目开发，时间紧，所以大多数情况可能还是选择不用外键这类的约束来加快开发速度，所有的表都是可以单独增删改查等操作，所以方便一些框架的使用，所以提高了开发速度。其实我在这种情况下也是这样做的。
如果在为自己做系统，或者做产品，以后自己会长期维护更新的系统时，我还是认为应该用上这些东西，后面的问题可能会更少。
总结：
其实就是又推荐使用一下外键，因这个也不是不能用，他有他的好处。