1、背景说明
在数据库的设计上，我们经常会看到许多系统存在大量结构相似的表。你可能会想，为什么这些表不能合并为一个表。在你仔细的思考这个问题时，你可能会发现以下难以解决的问题。
- 外键来至不同的主表，而主键采用的是自增长方式，合成一张表后避免不了冲突。
- 合成一张表后，数据亮太大了，数据库无法承受。
问题1困扰我们的是，设计库设计的正向设计思想。我们在设计表的时候，在处理一对多的设计关系时，通常都会抽象出一主多从的概念。例如一个商品有多张展示图片这个需求，一般我们都会把商品当做主表，展示图片当做从表。正是这种思想束缚了我们了，才导致我们无法解决问题1.
问题2在过去几年前可能是个难题，现在随着分表技术和nosql技术的成熟，基本是已不是什么问题了。
2、反向设计
最近几年，互联网系统流行的一个词就是服务化。当我们用服务化的思想来思考问题1时，瞬间你会发现你已经走出了正向的设计思维。我们把存储文件url的表当做主表时，其他的商品、车子、房子等主体，都是从表，需要关联文件url表。下面来两张设计对比图。
现在不管你的系统有多少张（一对多）图片表，你只需设计一张表，写一份代码，整个系统都可以使用。
下面在细说下方向设计，在业务中怎么用。举个例子：一个提交表单中，可以上传许多文件。通常的做法都是先上传文件到服务器，服务器返回一个url给客户端，最后提交表单的数据是url而不是文件本身。后台在处理表单数据时，按以下顺序执行。
- 业务方把所有的url数据一次给图片存储服务。
- 图片存储服务生成一个全局唯一的关联key。
- 图片存储服务保存url数据和关联key到数据库。
- 返回关联key给业务方
- 业务方存储自身业务数据和关联key
3、总结
反向设计不仅仅是精简了数据库，更重要的是体现了系统架构中的服务化的思想，我们由此可以把图片（文件）url存储抽离成一个独立的服务，业务方通过一个全局唯一的关联key查询修改删除图片。随着图片数量的增多，底层是采用分表技术还是nosql技术，对业务方来说是不用操心的。
