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

Path 7月前 110

1、创建人存的是 ID 还是 name?id 的话关联查询方便,name 的话展示更方便,不需要关联查询

2、扩展字段的存储结构是一个字段中存 json 还是单独一个属性表(id,userId,keyname,value)。

3、图片字段直接存 URL,还是单独一个资源表,图片字段关联资源表

另外问下有没有这方面的书籍或文章推荐?


最新回复 (15)
  • 绝望法师 7月前
    引用 2
    这么多次点击没有一个回复, 我也关注下
  • AiDey 7月前
    引用 3
    1. 存 id,如果 name 经常用可以冗余,但是要注意更新问题
    2. 存 json
    3. 存 url,数据库不存二进制文件
  • pufengzai0 7月前
    引用 4
    id,json,相对路径
  • h2o 7月前
    引用 5
    1.2 试试 NOSQL 类的数据库
    3. URL(小图片我还是觉得直接存 BASE64 省事)
  • dengdaibingning 7月前
    引用 6
    存 ID
    单独表,但表的 value 可以存入 json,或者序列化的对象。
    单独表,id 关联
  • kivim 7月前
    引用 7
    这几个问题好像都涉及到关系模式、数据库范式相关的概念;一般的数据库教程都会讲。
  • qxwo 7月前
    引用 8
    图片扔给 CDN,数据库里存 hash 或 url
  • zzz911 7月前
    引用 9
    1 存的 id,关联查询的话可以做成一个 view
    2 存成一个属性表,但是部分关联紧密的数据会直接在属性表里存为一个 json
    3 资源表做关联
  • savior 7月前
    引用 10
    我正在培养只通过程序访问数据的习惯,所以存什么对我来说都是展示方便,所以用户存 ID。

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

    图片资源,不能复用的直接存路径(比如同时只能存在一张的背景图),能复用的用资源表(比如同时可以存在几个的头像,当前头像和历史头像)。
  • hihandbag 7月前
    引用 11
    1:肯定是存 id,这里的关联是必须的,存 name 的话,一是重复,二是修改 name 后怎么处理
    2:拓展字段存 json,解析交给程序处理
    3:直接存 url
  • wagumaxida 7月前
    引用 12
    汪!汪!汪!
  • hxyz 7月前
    引用 13
    书的话 Bill Karwin 的 sql antipatterns 全书都是讲的类似问题,各种方案的利弊都将的很清楚了,根据实际情况分析
  • blanco 7月前
    引用 14
    1. 存 id,因为不知道后期需求,name 会不会允许重复,允许变更等等。

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

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

    个人习惯,数据库尽量规范化,不要提早做优化。性能出了问题先尝试缓存、读写分离等等,最后再考虑反规范化。
  • sh3dowin 7月前
    引用 15
    存 id,如果存 name 的话,只是展示好看一点,但是如果需要展示那个用户的一些其他信息或者那个用户的 name 改了,就没办法了

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

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

    第二个,这种感觉 NoSQL 更能应付,一般都是铺开用 column,如果涉及到数组,估计又要弄张 N 表
  • xiaoluo 7月前
    引用 16
    存 name 得考虑这个 name 是否会编辑, 如果会编辑, 那这个用户在更新了信息之后, 得同步去维护这张表的 name;

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

    所以建议存 ID;
返回
发新帖