本帖最后由 jiangcj369 于 2024-11-22 11:16 编辑
数据库三范式到底是啥，这里不多说了，想了解的朋友可以某度。
这里只探讨3NF的取舍问题，更主要的是针对使用活字格时3NF的取舍问题。
讨论原因：当一个订单表及详情表数据量都达到一定程度时，你这个严格遵守3NF要求设计的主子表会有怎样的反应？
1.订单表中客户ID关联到客户表，其他相关参数ID，比如税率ID关联到税率表
2.订单详情表中存货ID关联到存货ID，还有一些其他的ID关联。
这每一个ID意味着数据展示查询时都是一个JOIN连接。如果相应的表记录都达到一定数量级的时候，这个绑定了订单信息的活字格页面会有怎样的加载效率和查询效率呢？
我测试过订单表及详表冗余字段，及下沉字段的设计；也试过完全3NF下的设计，在百万级数据下，实际差距巨大！！！
（所谓冗余就是比如订单表中存客户名称，存税率值，详表中存品名，规格，单位这些字段，所谓下沉就是将订单表中的单号，日期，客户名称，税率这些也设计到详表中保存，查询的时候就可以只查询详表，不用管订单表，因为详表中也有主表的信息）。
大型成品系统比如用友这些基本都是冗余了大量字段，能单表查询的，不去多表JOIN查询。
个人结论：
1.表设计过程中有些设定好基本不会改变的基础信息字段，建议一律冗余到业务表中，比如词典表的值，而不是通过词典表ID去关联；再比如税率中的值直接设计到业务表，而不是用税率表ID去关联；
2.业务表中预估未来会进行大量查询的字段建议一律冗余到业务表中，不要通过基表ID关联；
3.原本可以通过字段计算得到的字段建议冗余进来，比如数量，含税单价，税率，正常来说只需要这三个我们就可以得到无税单价，无税金额，含税金额，税额等字段，你可能会说我想省几个字段，用的时候再用公式计算；这样使用时抛去计算结果偏差外，主要的就是性能问题了，所以这些字段建议也保存下来！
可以说，冗余用的好，系统运行效率会好太多；有人会说，3NF可以一改全改，那么我想问的是绝大多数情况下，不应该是要一改全改的，不改历史记录，反而有好处，历史记录可以作为数据变迁和追责的依据。
现在业界流行一个新的玩法，就是凡是皆是insert，尽量杜绝update和delete。
有人说我的存货信息表中某个物料品名用了好久，有一天突然想改了，我想一改全改，我想说，这种思想得治，历史数据有什么改的必要呢？物料这种基础信息建立的时候有一个唯一的物料编号，其他就是品名什么的，我想真要改品名，也应该是一些不改变物品实质的改动，你总不能今天这个物料叫手机，明天想改成鸡蛋吧，那为什么不新增一个物料叫鸡蛋呢？
总之，如果预估自己的活字格应用未来会有较大数据量，交频繁的查询等情况，推荐能冗余的字段尽量去冗余吧，别抱着3NF不放了；你会发现冗余了字段后，你会少用很多的JOIN关联，查询速度也快了，页面加载速度也上来了。
|
陕公网安备：61019002000258 |
隐私政策 |
网站地图