请教下 V 友的数据库设计习惯

这么多次点击没有一个回复， 我也关注下

1. 存 id，如果 name 经常用可以冗余，但是要注意更新问题
2. 存 json
3. 存 url，数据库不存二进制文件

id,json,相对路径

1.2 试试 NOSQL 类的数据库
3. URL(小图片我还是觉得直接存 BASE64 省事)

存 ID
单独表，但表的 value 可以存入 json，或者序列化的对象。
单独表，id 关联

这几个问题好像都涉及到关系模式、数据库范式相关的概念；一般的数据库教程都会讲。

图片扔给 CDN，数据库里存 hash 或 url

1 存的 id，关联查询的话可以做成一个 view
2 存成一个属性表，但是部分关联紧密的数据会直接在属性表里存为一个 json
3 资源表做关联

我正在培养只通过程序访问数据的习惯，所以存什么对我来说都是展示方便，所以用户存 ID。

扩展字段用单独属性表，方便查询。

图片资源，不能复用的直接存路径（比如同时只能存在一张的背景图），能复用的用资源表（比如同时可以存在几个的头像，当前头像和历史头像）。

1：肯定是存 id，这里的关联是必须的，存 name 的话，一是重复，二是修改 name 后怎么处理
2：拓展字段存 json，解析交给程序处理
3：直接存 url

汪！汪！汪！

书的话 Bill Karwin 的 sql antipatterns 全书都是讲的类似问题，各种方案的利弊都将的很清楚了，根据实际情况分析

1. 存 id，因为不知道后期需求，name 会不会允许重复，允许变更等等。

2. 看类型，比如一个插件需要保存用户相关的数据，那么直接建立一个这个插件的 user 扩展表，id 关联到 user 表。能不使用 json 就不使用。

3. 单独的关联表，但是不是直接将图片保存到数据库。关联表保存的也是图片路径。目的是方便追踪图片是哪个用户上传的，哪个资源依赖这个图片。另外后期图片可能迁移，单独的图片表迁移比较方便。

个人习惯，数据库尽量规范化，不要提早做优化。性能出了问题先尝试缓存、读写分离等等，最后再考虑反规范化。

存 id，如果存 name 的话，只是展示好看一点，但是如果需要展示那个用户的一些其他信息或者那个用户的 name 改了，就没办法了

如果该服务跟用户服务是同一个服务，同一个数据库，可以直接表连接，有外键约束的话就很快。
还有一种方式，适用于微服务，就是列表查下来后，收集 id，然后再一次性批量把用户的信息查过来，然后再去设置

但是这样的话，拼装的代码就会很烦，GraphQL 也许可以解决此痛点。

第二个，这种感觉 NoSQL 更能应付，一般都是铺开用 column，如果涉及到数组，估计又要弄张 N 表

存 name 得考虑这个 name 是否会编辑, 如果会编辑, 那这个用户在更新了信息之后, 得同步去维护这张表的 name;

而且 name 是否允许重复, 如果允许, 有多个相同 name 时, 到底是哪个;

所以建议存 ID;