V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
lawsiki
V2EX  ›  程序员

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

  •  
  •   lawsiki · 2019-12-19 14:34:59 +08:00 · 3356 次点击
    这是一个创建于 1561 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

    15 条回复    2019-12-19 18:40:16 +08:00
    lskjdfgl
        1
    lskjdfgl  
       2019-12-19 14:46:56 +08:00
    这么多次点击没有一个回复, 我也关注下
    Ahaochan
        2
    Ahaochan  
       2019-12-19 14:48:08 +08:00
    1. 存 id,如果 name 经常用可以冗余,但是要注意更新问题
    2. 存 json
    3. 存 url,数据库不存二进制文件
    Jiajin
        3
    Jiajin  
       2019-12-19 14:49:44 +08:00
    id,json,相对路径
    kkniub
        4
    kkniub  
       2019-12-19 14:51:51 +08:00
    1.2 试试 NOSQL 类的数据库
    3. URL(小图片我还是觉得直接存 BASE64 省事)
    falcon05
        5
    falcon05  
       2019-12-19 14:59:28 +08:00 via iPhone
    存 ID
    单独表,但表的 value 可以存入 json,或者序列化的对象。
    单独表,id 关联
    lower
        6
    lower  
       2019-12-19 15:13:06 +08:00
    这几个问题好像都涉及到关系模式、数据库范式相关的概念;一般的数据库教程都会讲。
    zappos
        7
    zappos  
       2019-12-19 15:18:01 +08:00
    图片扔给 CDN,数据库里存 hash 或 url
    vibbow
        8
    vibbow  
       2019-12-19 15:20:06 +08:00 via Android
    1 存的 id,关联查询的话可以做成一个 view
    2 存成一个属性表,但是部分关联紧密的数据会直接在属性表里存为一个 json
    3 资源表做关联
    eason1874
        9
    eason1874  
       2019-12-19 15:21:59 +08:00
    我正在培养只通过程序访问数据的习惯,所以存什么对我来说都是展示方便,所以用户存 ID。

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

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

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

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

    个人习惯,数据库尽量规范化,不要提早做优化。性能出了问题先尝试缓存、读写分离等等,最后再考虑反规范化。
    qwerthhusn
        14
    qwerthhusn  
       2019-12-19 16:22:18 +08:00
    存 id,如果存 name 的话,只是展示好看一点,但是如果需要展示那个用户的一些其他信息或者那个用户的 name 改了,就没办法了

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

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

    第二个,这种感觉 NoSQL 更能应付,一般都是铺开用 column,如果涉及到数组,估计又要弄张 N 表
    Kili9
        15
    Kili9  
       2019-12-19 18:40:16 +08:00
    存 name 得考虑这个 name 是否会编辑, 如果会编辑, 那这个用户在更新了信息之后, 得同步去维护这张表的 name;

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

    所以建议存 ID;
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5190 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 34ms · UTC 01:21 · PVG 09:21 · LAX 18:21 · JFK 21:21
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.