这是一个创建于 1133 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
joApioVVx4M4X6Rf 2021-10-22 11:53:42 +08:00
同问。感觉这东西很依赖经验
|
 |
2
40EaE5uJO3Xt1VVa 2021-10-22 11:54:33 +08:00
一样求教
|
 |
3
liuzhedash 2021-10-22 11:56:55 +08:00  2
|
 |
4
kikione OP @liuzhedash 感谢
|
 |
5
leonme 2021-10-22 12:16:16 +08:00 via iPhone
了解基本范式之后，其实依赖于你对业务系统的理解
|
 |
6
tabris17 2021-10-22 12:43:08 +08:00
@liuzhedash 这表结构设计得很糟糕，密码和用户信息竟然放在一张表里
|
 |
7
cnoder 2021-10-22 13:00:06 +08:00
为了是方便存、取、修改以及扩展，范式+一些小技巧+业务理解+自己的思考
|
 |
8
flniu 2021-10-22 13:55:51 +08:00 4
推荐两本书：
《数据库系统概念（原书第 7 版）》 https://book.douban.com/subject/35501216/ 《数据密集型应用系统设计》 https://book.douban.com/subject/30329536/ 当然这两本都比较大部头。但如果在初入职场的时候花几周时间爬完这两本，绝对受益整个职业生涯。 |
 |
15
wangpugod2003 2021-10-22 14:58:56 +08:00
以前的单体服务 MVC 的时代和实现的微服务时代，都不同，演进很多代了。
现在的微服务时代，数据库设计是轻量级的。例如外键，以前很流行，现在基本不用了。 建议从项目实践中模仿到提升，从设计 1：1，1：n 开始，到 n：n 。很多时候不走一些弯路是不知道为什么那样设计不好。 |
 |
16
allstack 2021-10-22 15:01:17 +08:00
尽量遵循三范式
|
 |
18
liuxey 2021-10-22 15:06:40 +08:00
规范毕竟是死的，能否设计出高效易用的表结构对经验要求极高。慢慢来吧，趟的坑多了就知道了
|
 |
19
saulshao 2021-10-22 15:17:31 +08:00
数据库设计确实很大程度上依赖于经验，能提供给你的书讲的都是原则性的东西。
跟怎么用 Spring 框架类的书比较，数据库设计类的书更像是反复在给你讲什么是类，类设计的通用原则是什么。 数据库设计从理论上来说，需要深刻理解范式，然后是集合论基础。 其它我觉得就完全依赖于经验和实践了。 正如上面提到的密码单独存张表，这其实是最近这些年的实践才有的。 其实大部分的企业应用，包括 ERP 、PDM 之类的系统，基本都是密码和用户名放一张表里。 |
 |
20
loux 2021-10-22 15:25:15 +08:00
@kanezeng 那属于业务上的扩展，第三方登录分表存储，密码不属于第三方在没有业务需求的情况下放一张表里没有什么问题，他那句话说的好像密码跟用户信息放一起是无法理解的事情一样。
|
 |
21
lower 2021-10-22 15:28:19 +08:00
如果特指 关系型数据库的话，关系模式 肯定是要了解的，范式。
不过这些都是为了你最终数据的查询、存取，怎么方便写 sql，怎么方便维护来搞。 |
|
23
tabris17 2021-10-22 16:19:36 +08:00
|
|
24
tabris17 2021-10-22 16:23:28 +08:00
@kiripeng 脱敏只是一部分原因。或者说是附加的额外优势，如果 User 和 Authentication 系统分开（逻辑上和数据上都分开），甚至可以做到 password 数据不落数据库，无论是用特殊硬件还是保密级别更高的数据库，自由度非常高
|
|
25
liuzhedash 2021-10-22 16:38:31 +08:00
|
|
27
tabris17 2021-10-22 16:49:49 +08:00
@liuzhedash 被产品坑个几次就知道拆表的好了
|
|
28
loux 2021-10-22 17:02:51 +08:00
@tabris17 用户名，手机号，邮箱，密码都是用户输入的，属于用户信息，用户可以随意修改，放在用户表并没有什么问题。比对密码的认证逻辑和第三方平台的认证逻辑完全不同，可以根据登录参数去区分认证方式。用户可操作的信息为什么要分开存储，在业务上不是麻烦自己吗？如果你的认证系统和业务系统是分开的（逻辑上和数据上都分开），用户需要修改这些信息的时候，你还要在认证系统开发额外的修改业务吗？
|
 |
31
sy20030260 2021-10-22 17:32:40 +08:00
只考虑「数据库设计」意义不大，得放在「系统设计」这个大问题下面来思考。没有什么 app 是只有数据库就能 run 的，同理数据库设计和 API 设计、架构设计、业务逻辑设计等问题都是无法分开讨论的。所以大厂面试考的都是系统设计题，而不是数据库设计题
|
 |
32
xiaochong 2021-10-22 17:36:17 +08:00 1
推荐 《 SQL 反模式》 https://book.douban.com/subject/6800774/
|
|
33
tabris17 2021-10-22 17:42:27 +08:00
@loux 这个副作用的确存在。但是邮箱手机解绑和重新绑定本身就是身份认证系统的业务，而不是用户系统的业务。认证系统重新绑定邮箱和手机后，可以通知用户系统更新 user profile 里的数据。用户系统不用验证邮箱和手机的惟一性，交给认证系统处理就好了
|
 |
35
x940727 2021-10-22 18:16:52 +08:00
@tabris17 如果是单体服务呢……为什么上来就是各种拆分业务系统，能有几个人用啊？数据库的设计从来都是要根据当时情况来设计的，你一上来就是这个服务那个服务，这个认证系统以后考虑到几年后的场景了，没有什么意义，徒增工作量和复杂度而已。
|
 |
37
NakeSnail 2021-10-22 20:35:53 +08:00 1
最大的感触就是少关联，多冗余
|
 |
38
kytrun 2021-10-22 22:08:26 +08:00 via Android
做几个无厘头变更及扩展需求的项目就比较有体会了🐶
|
 |
39
akira 2021-10-23 04:29:40 +08:00 1
第一步，学好三范式
第二步，忘掉三范式 开玩笑的啦， 多看看别人是怎么设计的，基本上就可以上手了。 进一步的话，要求就比较多了，等到了那个时候 你再去研究更合适 |
Select Language