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

[kikione]

[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 密码是明文存的吗，需要脱敏