情景
这两日，我一直被某件事情苦恼着。
情景大概是这样的，我需要采集网络小说，建表的时候，我遇到了一个问题。
子表B里到底要不要设定一个外键与主表A联系起来？
分析
很多情况下，大多数的考虑肯定就是，当然是要的，
这既能提高查询性能，又能节省存储空间，
毕竟外键字段只是存储id而已，数据多起来以后，节省空间的效果是显著的。
嗯，没毛病，我就是这样想的。
但是后来，我在开发过程中让我意识到了，由于使用这个外键导致的开发难度的增加了数倍。
在使用爬虫采集数据的时候，由于这个外键的关系，
爬虫在插入数据库时，就必须优先插入主表A数据，
然后再查询这个主表A某条数据的id，
写入子表B的数据的外键字段中，
最后再执行子表插入。
原本的数据插入流程变成了：
插入→查询→修改→插入
咋一看，这似乎没什么大不了的，但是如果是多线程爬虫的话，这无疑访问数据库的数据就翻了数倍
如果数据库庞大的话，查询时间恐怕令人发指。
这之后还要考虑到增量更新的问题，那么这个开发的难度又会更上一层楼了。
所以，我到底要不要选择在这里使用外键，让我很是困扰。
寻找答案
于是，找到一篇博文，数据库中使用外键和不使用外键有什么区别
上面很好的探讨了该问题，其中反方观点中，第三点这样写到：
- 不用外键时数据管理简单，操作方便，性能高（导入导出等操作，在insert, update, delete 数据的时候更快）eg:在海量的数据库中想都不要去想外键，试想，一个程序每天要insert数百万条记录，当存在外键约束的时候，每次要去扫描此记录是否合格，一般还不止一个字段有外键，这样扫描的数量是成级数的增长！我的一个程序入库在3个小时做完，如果加上外键，需要28个小时！
这样描述就挺符合我现在遇到的问题。
文章的结论，总结是这样的：
在大型系统中（性能要求不高，安全要求高），使用外键；在大型系统中（性能要求高，安全自己控制），不用外键；
小系统随便，最好用外键。用外键要适当，不能过分追求。
不用外键而用程序控制数据一致性和完整性时，应该写一层来保证，然后各个应用通过这个层来访问数据库。
总结
我重新审视了一下，自己开发的个人项目。
首先，这是个人项目，它的定位并不是一个大型系统。
“小系统随便，最好用外键”，但是造成爬虫开发难度和采集时间的大幅增加，这不划算。
所以，虽然不甘心，但是应该放弃在这里使用外键。
