外键、触发器

外键、触发器不要有。

有了外键、触发器，你会发现：写代码不方便。订正数据不方便。迁移数据也麻烦。总之，你要是坚持用，后续的坑等着你。

自增id

数据库表，一定要有id，而且要用自增id！

有些人喜欢用自定义的，用UUID或者其他七七八八的id，如果在架构设计，代码比较好的情况下，不会出啥大问题，但是一旦代码写的不行，极有可能就造成id重复之类的问题。

自增id另外还有一个好处，就是在数据迁移的时候，分页查询通过id来进行分页，速度会比传统分页快太多太多。

创建时间和修改时间这两个字段，每个表都要有！注意，一定要用数据的时间戳，自动生成。不要通过代码去操作这两个字段。

有了这两个字段。你可以追溯到数据的时间点，创建和修改的时间点。极大方便你在某些情况下的排查数据问题。

建议每个表也有这两个字段

还是和前面一个原因，出问题的时候可以追溯起因，否则遇上日志过久无法查看或者其他原因出现未知数据，都不知道数据怎么来的，需要花非常大的代价查看日志、代码等

一列需要占很大空间的字段，一定要单独拎出来，不要和常用信息放一张表。

举个例子：文章的信息和文章的内容，这一定要分成两个表。否则会给你的文章性能带来极大的挑战。因为很多情况下，查看文章列表，根本不需要查看到文章的内容。

表与表之间的信息,用id进行关联，尽量不要有冗余的信息数据，否则你需要更新同一份信息的时候，需要更新多个地方。

但是在某些情况下，你确认信息不会经常变动，且该信息确实在两个表中都有会比较好，那么，放心的去冗余吧。但是注意，数据的更新用上事务。

这个原则我自己想出来的，也就是说，数据库中的一张表，只能有一个系统对其进行写操作。其他的系统如果想写这张表，那么经过调用这个系统的接口进行操作。

如果有多个系统写同一张表，可能带来的问题太多了。首先就是数据并发问题，另外就是事务问题，还有就是表结构变更问题，数据来源追溯问题等等

如果谁有一张表数据想用多个系统来进行写，那肯定是想把团队拖垮。时间越久，债务越多！

数据库设计，标准其实是在变的，不变的只是思想。

业务场景不同，实际需求不一样，不会存在一样的设计，但是通用的思想都是一样的，为了业务服务，为了未来服务，方便维护，方便扩展。

这条路很长，只能慢慢在路上体会了。