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

[joApioVVx4M4X6Rf]

同问。感觉这东西很依赖经验

[40EaE5uJO3Xt1VVa]

一样求教

[liuzhedash]

https://gitee.com/dcloud/opendb
供参考

[kikione]

@liuzhedash 感谢

[leonme]

了解基本范式之后，其实依赖于你对业务系统的理解

[tabris17]

@liuzhedash 这表结构设计得很糟糕，密码和用户信息竟然放在一张表里

[cnoder]

为了是方便存、取、修改以及扩展，范式+一些小技巧+业务理解+自己的思考

[flniu]

推荐两本书：
《数据库系统概念（原书第 7 版）》 https://book.douban.com/subject/35501216/
《数据密集型应用系统设计》 https://book.douban.com/subject/30329536/
当然这两本都比较大部头。但如果在初入职场的时候花几周时间爬完这两本，绝对受益整个职业生涯。

[qsnow6]

@tabris17 那应该如何设计，有资料吗

[qq8331199]

@tabris17 为什么不，说一下你的理由

[Yi23]

@qsnow6 登录方式和用户信息分开存储，使用用户 ID 进行关联。

[loux]

@tabris17 密码单独一张表的意义是什么？

[kiripeng]

@loux 数据脱敏吧

[qsnow6]

@kiripeng 这样设计的话好扩展第三方登录

[wangpugod2003]

以前的单体服务 MVC 的时代和实现的微服务时代，都不同，演进很多代了。
现在的微服务时代，数据库设计是轻量级的。例如外键，以前很流行，现在基本不用了。
建议从项目实践中模仿到提升，从设计 1：1，1：n 开始，到 n：n 。很多时候不走一些弯路是不知道为什么那样设计不好。

[allstack]

尽量遵循三范式

[kanezeng]

@loux 我觉得主要是现在的话，密码只是登录方式的一种，所以密码独立出来一张表，或者和其他登录方式整合

[liuxey]

规范毕竟是死的，能否设计出高效易用的表结构对经验要求极高。慢慢来吧，趟的坑多了就知道了

[saulshao]

数据库设计确实很大程度上依赖于经验，能提供给你的书讲的都是原则性的东西。
跟怎么用 Spring 框架类的书比较，数据库设计类的书更像是反复在给你讲什么是类，类设计的通用原则是什么。
数据库设计从理论上来说，需要深刻理解范式，然后是集合论基础。
其它我觉得就完全依赖于经验和实践了。
正如上面提到的密码单独存张表，这其实是最近这些年的实践才有的。
其实大部分的企业应用，包括 ERP 、PDM 之类的系统，基本都是密码和用户名放一张表里。

[loux]

@kanezeng 那属于业务上的扩展，第三方登录分表存储，密码不属于第三方在没有业务需求的情况下放一张表里没有什么问题，他那句话说的好像密码跟用户信息放一起是无法理解的事情一样。

[lower]

如果特指 关系型数据库的话，关系模式 肯定是要了解的，范式。
不过这些都是为了你最终数据的查询、存取，怎么方便写 sql，怎么方便维护来搞。

[fdgdbr]

@flniu 第二本读过，真是本好书，不管是新手还是有经验的都值得读

[tabris17]

@qsnow6
@qq8331199
@loux
@kiripeng

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

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

对于第三方平台认证的用户根本不需要密码字段。如果需要封禁一个用户，只要删除 Auth 表里用户对应的认证数据就行了。甚至可以控制一个用户允许通过哪些方式登录（认证）

[tabris17]

@kiripeng 脱敏只是一部分原因。或者说是附加的额外优势，如果 User 和 Authentication 系统分开（逻辑上和数据上都分开），甚至可以做到 password 数据不落数据库，无论是用特殊硬件还是保密级别更高的数据库，自由度非常高

[liuzhedash]

@tabris17 #6
老弟，你可是一口把话说死了。。

@kikione
如果没学过关系型数据库的课，可以看下 8 楼的资料。从工程实践的角度看，三范式是一个基本原则，需要尽可能遵守，同时为了维护方便、编码方便也可以做出妥协。
如果刚开始做一个业务系统的表结构设计，可以先把范式抛在脑后，集中精力和产品设计人员讨论业务模型到底需要哪些字段，它们之间的关系是什么，这是最重要的。

[ffxrqyzby]

@flniu 第二本同推, 能把所有关于数据相关的底层逻辑给讲清楚

[tabris17]

@liuzhedash 被产品坑个几次就知道拆表的好了

[loux]

@tabris17 用户名，手机号，邮箱，密码都是用户输入的，属于用户信息，用户可以随意修改，放在用户表并没有什么问题。比对密码的认证逻辑和第三方平台的认证逻辑完全不同，可以根据登录参数去区分认证方式。用户可操作的信息为什么要分开存储，在业务上不是麻烦自己吗？如果你的认证系统和业务系统是分开的（逻辑上和数据上都分开），用户需要修改这些信息的时候，你还要在认证系统开发额外的修改业务吗？

[jtwor]

@tabris17 想问一下 password 数据不落数据库的思路是怎样的？

[jtwor]

@jtwor 没看清楚前面，大概就是授权中心做登录的事情，密码就不用放 User 表

[sy20030260]

只考虑「数据库设计」意义不大，得放在「系统设计」这个大问题下面来思考。没有什么 app 是只有数据库就能 run 的，同理数据库设计和 API 设计、架构设计、业务逻辑设计等问题都是无法分开讨论的。所以大厂面试考的都是系统设计题，而不是数据库设计题

[xiaochong]

推荐 《 SQL 反模式》 https://book.douban.com/subject/6800774/

[tabris17]

@loux 这个副作用的确存在。但是邮箱手机解绑和重新绑定本身就是身份认证系统的业务，而不是用户系统的业务。认证系统重新绑定邮箱和手机后，可以通知用户系统更新 user profile 里的数据。用户系统不用验证邮箱和手机的惟一性，交给认证系统处理就好了

[tabris17]

@jtwor 提供服务接口就行了，你可以使用私有格式，甚至特殊的硬件，随意发挥

[x940727]

@tabris17 如果是单体服务呢……为什么上来就是各种拆分业务系统，能有几个人用啊？数据库的设计从来都是要根据当时情况来设计的，你一上来就是这个服务那个服务，这个认证系统以后考虑到几年后的场景了，没有什么意义，徒增工作量和复杂度而已。

[JasonLaw]

@flniu #8 我也是读这两本书，但几周是远远不够的😅。

[NakeSnail]

最大的感触就是少关联，多冗余

[kytrun]

做几个无厘头变更及扩展需求的项目就比较有体会了🐶

[akira]

第一步，学好三范式
第二步，忘掉三范式
开玩笑的啦， 多看看别人是怎么设计的，基本上就可以上手了。 进一步的话，要求就比较多了，等到了那个时候 你再去研究更合适

[levon]

@kiripeng 密码是明文存的吗，需要脱敏