最近在设计一个户外APP的数据库，在外键设计上有点纠结，用还是不用，考虑了再三，还是不用，
那么如何表之间的关联了。只能在字段名上做文章了。
比如在用户表里面的ID，最好写成userId
与之关联的相册表里面对应一个userId即可实现关联
参考1：
表的关联，只是一种逻辑概念，本并不需要进行物理上的“硬绑定”，而且你所期望的关联，其实只是其数据上存在一定的联系而已，而这种联系实际上是在设计之初就定义好的固有逻辑。
所以在业务代码中实现的时候，只要按照设计之初的这种固有关联逻辑来“存/取”数据即可，并不需要在数据库层面进行“硬绑定”，因为在数据库层面通过使用外键的方式进行“硬绑定”，会带来很多额外的资源消耗来进行一致性和完整性校验，即使很多时候我们并不需要这个校验。所以一般不建议在数据库中使用外键约束来保证数据的一致性和完整性。
参考2：
首先关于外键的作用与使用场景：1.作用：通过数据库提供的外键功能，进行数据完整性和一致性的维护，避免借助外部力量维护；2.使用场景：若是高并发大流量事务场景，使用外键可能容易造成死锁，以及数据库资源更快出现瓶颈，所以一般互联网行业不建议使用，多使用再企业内部，比如ERP软件，早期的MIS系统等关于如何体现表与表之间的关联性和如何维护数据完整性和一致性：1.关联性：那就是设计数据库的时候，要让所有人知道表与表之间的通过那个字段关联起来，所以字段名称命名上会做一些文章2. 如何维护数据完整性和一致性：通过外部程序的力量，启用事务的方式，比如：START TRANSACTION;UPDATE A SET co1=** ...;UPDATE B SET A_co1=**...;COMMIT;注释：假设场景 A表的col1变成某值之后，B表中的A_col1字段也必须修改为对应的值...