巩义网站建设价格建设网站的合同

巩义网站建设价格,建设网站的合同,百度扫一扫,厦门地税网站建设文章目录引言第一范式第二范式第三范式总结❤️引言 作为后端开发者#xff0c;项目初期进行库表设计的时候#xff0c;如果光凭经验而没有一套合适的方法论#xff0c;大概率项目最后会变成一个难以维护的“史山”。那么我们就来简单讲讲数据库表设计的三大范式#xff0c…文章目录引言第一范式第二范式第三范式总结❤️引言作为后端开发者项目初期进行库表设计的时候如果光凭经验而没有一套合适的方法论大概率项目最后会变成一个难以维护的“史山”。那么我们就来简单讲讲数据库表设计的三大范式尽量都让大家听懂我们的最终目的是大家掌握应对各种业务场景设计的思维框架第一范式第一范式确保关系中的所有属性列都是不可再分的原子性值。具体含义表中的每一个字段都不可再分。不允许在同一列中存储多个值例如一个“联系方式”字段不能包含“电话号码, 电子邮件地址”。不允许在表中创建“重复组”——即一个记录行中不能有多个重复的字段例如“产品1, 产品2, 产品3”举个例子来回答不允许在同一列中存储多个值比如说地址这个列你不能存储成广东省广州市xx区xx街道…这样整个字符串这样地址还可以再进行拆分而是你要拆成直到不能再进行拆分的原子字段比如省市区等等。一个记录行中不能有多个重复的字段比如说课程里面你不能同时记录数学语文等等而是应该分开多个行进行记录第二范式第二范式要求每一列(非主键字段)都完全依赖于主键具体含义如果一个表的主键是联合主键由多个列组成那么所有非主键列都必须依赖于整个联合主键。如果任何一个非主键列只依赖于联合主键中的部分列则违反了 2NF。这会导致“部分函数依赖”。举个例子来解释第二范式订单表里面就不能出现商品的库存信息因为商品的库存信息依赖于商品的ID而不依赖于订单ID。那么简单来说就是表里面的每个列都必须完全依赖于主键不管这个主键是联合主键还是独立主键不能出现部分依赖的情况否则就要拆分部分依赖的列到其他表里面去。再举个违反 2NF 的例子假设订单ID和产品ID组成联合主键订单ID产品ID订单日期产品名称产品价格1001A1012025-12-15笔记本电脑80001001B2052025-12-15鼠标1501002A1012025-12-16笔记本电脑8000问题产品名称和产品价格只依赖于产品ID(主键的一部分)与订单ID无关。这就是部分函数依赖第三范式第三范式每一列都必须直接依赖于主键而不能间接依赖主键即不能存在依赖传递。换句话说任何非主键属性不能依赖于其他非主键属性。具体含义消除传递函数依赖。即如果A → B A \rightarrow BA→B且B → C B \rightarrow CB→C其中A AA是主键那么C CC对A AA就是传递依赖需要消除举个例子来解释第三范式订单表里面有用户ID就不应该还冗余一列用户的注册时间。因为用户的注册时间依赖于用户ID(在订单表里面是非主键,在用户表里面是主键)所以用户的注册时间如果存在于订单表就是有间接依赖即依赖传递的情况。再举个违反 3NF 的例子假设客户ID是主键客户ID客户姓名所在城市城市邮编C001张三上海200000C002李四上海200000C003王五北京100000问题城市邮编依赖于所在城市而所在城市依赖于客户ID。客户 I D → 所在城市 → 城市邮编 客户ID \rightarrow 所在城市 \rightarrow 城市邮编客户ID→所在城市→城市邮编这就是传递函数依赖。每次有新的上海客户加入城市邮编都会重复存储。总结❤️在实际的数据库设计中通常会努力达到 3NF。然而有时为了提高查询性能可能会故意违反 3NF采用反范式设计。为业务做出的妥协是可以理解的我推荐大家可以利用DDD领域驱动设计的维度去结合三大范式来进行库表设计比如在订单领域地址就可以是订单表的列可以冗余。在用户领域地址就应该是一个实体可以进行增删改查和独立的业务意义有完整的生命周期。简单来说就是在用户领域地址应该被设置成一个单独ID的表而在订单领域地址只是一个值对象(无生命周期下单即固化类似于快照)什么该冗余什么不该冗余有了一个切合实际的思维框架而不是依赖于经验之谈对项目的可维护性会有很大帮助