V2EX › 程序员

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

kikione · 1 天前 · 2439 次点击

40 条回复 • 2021-10-23 11:28:31 +08:00

v2exblog 1 天前

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

yanzhiling2001 1 天前

leonme 1 天前 via iPhone

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

tabris17 1 天前

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

cnoder 1 天前

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

qsnow6 1 天前

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

qq8331199 1 天前

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

Yi23 1 天前

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

loux 1 天前

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

qsnow6 1 天前

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

wangpugod2003 1 天前

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

allstack 1 天前

尽量遵循三范式

kanezeng 1 天前

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

liuxey 1 天前

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

saulshao 1 天前

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

loux 1 天前

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

lower 1 天前

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

fdgdbr 1 天前

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

tabris17 1 天前

@qsnow6
@qq8331199
@loux
@kiripeng

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

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

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

tabris17 1 天前

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

liuzhedash 1 天前

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

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

ffxrqyzby 1 天前

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

tabris17 1 天前

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

loux 1 天前

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