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

数据库的业务表如何设计?有什么方法论吗?各位有什么资料让我学习一下,谢谢!

  •  1
     
  •   kikione · 36 天前 · 2856 次点击
    这是一个创建于 36 天前的主题,其中的信息可能已经有所发展或是发生改变。
    40 条回复    2021-10-23 11:28:31 +08:00
    v2exblog
        1
    v2exblog   36 天前
    同问。感觉这东西很依赖经验
    yanzhiling2001
        2
    yanzhiling2001   36 天前
    一样求教
    liuzhedash
        3
    liuzhedash   36 天前   ❤️ 2
    kikione
        4
    kikione   36 天前
    @liuzhedash 感谢
    leonme
        5
    leonme   36 天前 via iPhone
    了解基本范式之后,其实依赖于你对业务系统的理解
    tabris17
        6
    tabris17   36 天前
    @liuzhedash 这表结构设计得很糟糕,密码和用户信息竟然放在一张表里
    cnoder
        7
    cnoder   36 天前
    为了是方便存、取、修改以及扩展,范式+一些小技巧+业务理解+自己的思考
    flniu
        8
    flniu   36 天前   ❤️ 4
    推荐两本书:
    《数据库系统概念(原书第 7 版)》 https://book.douban.com/subject/35501216/
    《数据密集型应用系统设计》 https://book.douban.com/subject/30329536/
    当然这两本都比较大部头。但如果在初入职场的时候花几周时间爬完这两本,绝对受益整个职业生涯。
    qsnow6
        9
    qsnow6   36 天前
    @tabris17 那应该如何设计,有资料吗
    qq8331199
        10
    qq8331199   36 天前
    @tabris17 为什么不,说一下你的理由
    Yi23
        11
    Yi23   36 天前
    @qsnow6 登录方式和用户信息分开存储,使用用户 ID 进行关联。
    loux
        12
    loux   36 天前
    @tabris17 密码单独一张表的意义是什么?
    kiripeng
        13
    kiripeng   36 天前
    @loux 数据脱敏吧
    qsnow6
        14
    qsnow6   36 天前
    @kiripeng 这样设计的话好扩展第三方登录
    wangpugod2003
        15
    wangpugod2003   36 天前
    以前的单体服务 MVC 的时代和实现的微服务时代,都不同,演进很多代了。
    现在的微服务时代,数据库设计是轻量级的。例如外键,以前很流行,现在基本不用了。
    建议从项目实践中模仿到提升,从设计 1:1,1:n 开始,到 n:n 。很多时候不走一些弯路是不知道为什么那样设计不好。
    allstack
        16
    allstack   36 天前
    尽量遵循三范式
    kanezeng
        17
    kanezeng   36 天前
    @loux 我觉得主要是现在的话,密码只是登录方式的一种,所以密码独立出来一张表,或者和其他登录方式整合
    liuxey
        18
    liuxey   36 天前
    规范毕竟是死的,能否设计出高效易用的表结构对经验要求极高。慢慢来吧,趟的坑多了就知道了
    saulshao
        19
    saulshao   36 天前
    数据库设计确实很大程度上依赖于经验,能提供给你的书讲的都是原则性的东西。
    跟怎么用 Spring 框架类的书比较,数据库设计类的书更像是反复在给你讲什么是类,类设计的通用原则是什么。
    数据库设计从理论上来说,需要深刻理解范式,然后是集合论基础。
    其它我觉得就完全依赖于经验和实践了。
    正如上面提到的密码单独存张表,这其实是最近这些年的实践才有的。
    其实大部分的企业应用,包括 ERP 、PDM 之类的系统,基本都是密码和用户名放一张表里。
    loux
        20
    loux   36 天前
    @kanezeng 那属于业务上的扩展,第三方登录分表存储,密码不属于第三方在没有业务需求的情况下放一张表里没有什么问题,他那句话说的好像密码跟用户信息放一起是无法理解的事情一样。
    lower
        21
    lower   36 天前
    如果特指 关系型数据库的话,关系模式 肯定是要了解的,范式。
    不过这些都是为了你最终数据的查询、存取,怎么方便写 sql,怎么方便维护来搞。
    fdgdbr
        22
    fdgdbr   36 天前
    @flniu 第二本读过,真是本好书,不管是新手还是有经验的都值得读
    tabris17
        23
    tabris17   36 天前
    @qsnow6
    @qq8331199
    @loux
    @kiripeng

    理由很简单,用户(User)和认证(Authentication)是两码事,小型系统混在一起没关系,既然做的是通用架构,那就不应该混在一张表里。用户放在 User 表里,认证信息放在 Auth 表里。

    谁规定一个用户只能有一种登录(认证)方式的?除了用户名+密码的方式,手机号+密码行不行?邮箱+密码行不行?用户名+一次性 TOTP 行不行?

    对于第三方平台认证的用户根本不需要密码字段。如果需要封禁一个用户,只要删除 Auth 表里用户对应的认证数据就行了。甚至可以控制一个用户允许通过哪些方式登录(认证)
    tabris17
        24
    tabris17   36 天前
    @kiripeng 脱敏只是一部分原因。或者说是附加的额外优势,如果 User 和 Authentication 系统分开(逻辑上和数据上都分开),甚至可以做到 password 数据不落数据库,无论是用特殊硬件还是保密级别更高的数据库,自由度非常高
    liuzhedash
        25
    liuzhedash   36 天前
    @tabris17 #6
    老弟,你可是一口把话说死了。。

    @kikione
    如果没学过关系型数据库的课,可以看下 8 楼的资料。从工程实践的角度看,三范式是一个基本原则,需要尽可能遵守,同时为了维护方便、编码方便也可以做出妥协。
    如果刚开始做一个业务系统的表结构设计,可以先把范式抛在脑后,集中精力和产品设计人员讨论业务模型到底需要哪些字段,它们之间的关系是什么,这是最重要的。
    ffxrqyzby
        26
    ffxrqyzby   36 天前
    @flniu 第二本同推, 能把所有关于数据相关的底层逻辑给讲清楚
    tabris17
        27
    tabris17   36 天前
    @liuzhedash 被产品坑个几次就知道拆表的好了
    loux
        28
    loux   36 天前
    @tabris17 用户名,手机号,邮箱,密码都是用户输入的,属于用户信息,用户可以随意修改,放在用户表并没有什么问题。比对密码的认证逻辑和第三方平台的认证逻辑完全不同,可以根据登录参数去区分认证方式。用户可操作的信息为什么要分开存储,在业务上不是麻烦自己吗?如果你的认证系统和业务系统是分开的(逻辑上和数据上都分开),用户需要修改这些信息的时候,你还要在认证系统开发额外的修改业务吗?
    jtwor
        29
    jtwor   36 天前
    @tabris17 想问一下 password 数据不落数据库的思路是怎样的?
    jtwor
        30
    jtwor   36 天前
    @jtwor 没看清楚前面,大概就是授权中心做登录的事情,密码就不用放 User 表
    sy20030260
        31
    sy20030260   36 天前
    只考虑「数据库设计」意义不大,得放在「系统设计」这个大问题下面来思考。没有什么 app 是只有数据库就能 run 的,同理数据库设计和 API 设计、架构设计、业务逻辑设计等问题都是无法分开讨论的。所以大厂面试考的都是系统设计题,而不是数据库设计题
    xiaochong
        32
    xiaochong   36 天前   ❤️ 1
    推荐 《 SQL 反模式》 https://book.douban.com/subject/6800774/
    tabris17
        33
    tabris17   36 天前
    @loux 这个副作用的确存在。但是邮箱手机解绑和重新绑定本身就是身份认证系统的业务,而不是用户系统的业务。认证系统重新绑定邮箱和手机后,可以通知用户系统更新 user profile 里的数据。用户系统不用验证邮箱和手机的惟一性,交给认证系统处理就好了
    tabris17
        34
    tabris17   36 天前
    @jtwor 提供服务接口就行了,你可以使用私有格式,甚至特殊的硬件,随意发挥
    x940727
        35
    x940727   36 天前
    @tabris17 如果是单体服务呢……为什么上来就是各种拆分业务系统,能有几个人用啊?数据库的设计从来都是要根据当时情况来设计的,你一上来就是这个服务那个服务,这个认证系统以后考虑到几年后的场景了,没有什么意义,徒增工作量和复杂度而已。
    JasonLaw
        36
    JasonLaw   36 天前
    @flniu #8 我也是读这两本书,但几周是远远不够的😅。
    NakeSnail
        37
    NakeSnail   36 天前   ❤️ 1
    最大的感触就是少关联,多冗余
    kytrun
        38
    kytrun   35 天前 via Android
    做几个无厘头变更及扩展需求的项目就比较有体会了🐶
    akira
        39
    akira   35 天前   ❤️ 1
    第一步,学好三范式
    第二步,忘掉三范式
    开玩笑的啦, 多看看别人是怎么设计的,基本上就可以上手了。 进一步的话,要求就比较多了,等到了那个时候 你再去研究更合适
    levon
        40
    levon   35 天前
    @kiripeng 密码是明文存的吗,需要脱敏
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2322 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 37ms · UTC 12:49 · PVG 20:49 · LAX 04:49 · JFK 07:49
    ♥ Do have faith in what you're doing.