标签：编码 范式 数据库 A001 商品 款码 100

数据库范式是为了规范数据库表结构设计，使结构更合理，消除存储异常，使数据冗余尽量小。便于插入、删除和更新。

第一范式：列不可再拆分

列指的字段或者叫属性，所有的字段都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。
例如：

每个字段的含义是明确的，但事实上在某些情况会违反这一原则，称之为反模式，例如加一个扩展字段，该字段内容是个json，可以动态添加一些非常用的字段，比如{"产地":"XX","生产批次":"XXXX"}，好处是当不是每一条记录都必然会出现的字段需要存储时，不用额外增加字段，可以随意插入，坏处就是万一用到扩展字段作为搜索查询条件，将无法满足查询的需求。

第二范式：非主属性完全依赖于主键

数据库里的每个字段都应该和主键相关联，并完全依赖于主键，

通过商品编码可以找到商品款码
通过商品编码可以找到商品名称
通过商品编码可以找到商品售价
通过商品编码可以找到商品销售属性

第三范式：消除传递依赖（任何非主属性不依赖于其它非主属性）

在这张表里 商品名称其实可以依赖于商品款码，可以将商品的款作为单独的表，将上述表拆成两部分。
SKU表

Item表

如果严格按照范式设计数据库，更新数据时影响的范围会比较小，比如更新商品款式的名称时只需要更新Item表的一条记录就行了，不需要更新所有SKU表记录内容，但是查询的时候就需要联表查询，如果数据表的数据量很大就会造成查询性能下降，有时候需要适当的冗余数据列来提高查询性能。

标签：编码,范式,数据库,A001,商品,款码,100
来源： https://www.cnblogs.com/sands/p/16504180.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。