请选择 进入手机版 | 继续访问电脑版
 找回密码
 立即注册

QQ登录

只需一步,快速开始

jiangcj369

中级会员

56

主题

262

帖子

904

积分

中级会员

积分
904

[使用感受] 再谈数据库范式3NF

jiangcj369
中级会员   /  发表于:2024-11-22 11:09  /   查看:259  /  回复:13
本帖最后由 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关联,查询速度也快了,页面加载速度也上来了。


评分

参与人数 1金币 +666 收起 理由
Grayson.Shang + 666 向大佬学习,赞一个!

查看全部评分

13 个回复

倒序浏览
chinameng
中级会员   /  发表于:2024-11-22 12:58:50
沙发
这是确实是有经验之谈,在ERP中,除了新增加单据时,从商品档案获取,也就是输入品号带出名称和规格以外,将来引用上游单据的一律取上游单据的名称而不是取商品档案,这样最大的好处上下游单据一致,像有了单价税率尽量再保存金额,将来作报表或看板展示时,会减少很多麻烦。
回复 使用道具 举报
137294886
金牌服务用户   /  发表于:2024-11-23 00:11:23
板凳
学习了
回复 使用道具 举报
vickdracula活字格认证
高级会员   /  发表于:2024-11-23 08:29:04
地板
没错,实际操作过程不能放着3NF不放,实事求是才是好系统。
回复 使用道具 举报
amtath悬赏达人认证 活字格认证
论坛元老   /  发表于:2024-11-23 09:11:57
5#
有没有大佬进来反驳他
回复 使用道具 举报
jiangcj369
中级会员   /  发表于:2024-11-23 09:15:56
6#
本帖最后由 jiangcj369 于 2024-11-23 09:18 编辑
amtath 发表于 2024-11-23 09:11
有没有大佬进来反驳他


过分追求3NF是活字格慢的重要元凶,想想看吧,一个表上join五六个表,儿这五六个表都有上百万挑数据。。酸爽,有人测试过每增加一个join,效率成好几倍的下降
回复 使用道具 举报
ZDYW悬赏达人认证 活字格认证
金牌服务用户   /  发表于:2024-11-23 09:59:31
7#
回复 使用道具 举报
amtath悬赏达人认证 活字格认证
论坛元老   /  发表于:2024-11-23 10:09:21
8#
jiangcj369 发表于 2024-11-23 09:15
过分追求3NF是活字格慢的重要元凶,想想看吧,一个表上join五六个表,儿这五六个表都有上百万挑数据。 ...

呵呵,一个空工程也要转半天,是什么重要元凶
回复 使用道具 举报
jiangcj369
中级会员   /  发表于:2024-11-23 10:23:31
9#
本帖最后由 jiangcj369 于 2024-11-23 10:32 编辑
amtath 发表于 2024-11-23 10:09
呵呵,一个空工程也要转半天,是什么重要元凶

真这样的话,那活字格就没办法用了,啥像样的东西也做不了,空的或者几百条数据就慢的要死,这玩意用了干啥,说实话活字格设计器已经很庞大了,官方是为了迎合JAVA那些人非要搞什么JAVA工作流,JAVA插件,一下把NET CORE的高性能给托住了,已经很庞大,还在各种外挂,不如着手把现有的官方插件,官方控件给细节化,更实用;这样又能确保活字格功能够用,也可以保障运行的性能。啥东西都往里塞毕将带来各种兼容性问题。我猜想活字格设计器界面左侧几百个页面,上百个表,上百个视图,一大堆服务端命令,一大堆各级文件夹,我估计设计器会经常卡死。应该减负了,其实系统开发过程中使用最多的无非就是那几个单元格控件和其依赖的命令,以及表格和表格相关功能,表格是使用频率最高的,所以应该从显示,功能各方面给予细化。
回复 使用道具 举报
跷跷板
中级会员   /  发表于:2024-11-23 13:42:22
10#
本帖最后由 跷跷板 于 2024-11-23 13:43 编辑

我现在就遇到这个问题, 在做查询报表的时候,因为前端比较慢,所以做成SQL视图,但视图也要5,6个表left join 和inner join .     然后绑定到表格查询的时候很慢 。   
我现在是用用proc 将视图插入到实表中,再查实表。 这样性能才能保证 。   

jiangcj369的方法是值得可以好好考虑一下...数据大的时候,用户对操作的效率的要求还是很苛刻的。

回复 使用道具 举报
12下一页
您需要登录后才可以回帖 登录 | 立即注册
返回顶部