Work diary

2009-04-01

自上周末生病以来,人一直感觉没力气。偏偏还有两份压力容器管道之类的规范要翻译,只好慢慢干了。

历经一周,总算有点精神了。今天一算日子,发现已经是4月份了,好快!

MRP 的是无论如何要放在前面做,否则被老板说起来可就坏了。

 

前面的MRP试验,事隔多日,我又快忘光了。要重新激起回忆,只好再往程序里走一趟。

 

问仓库要了个材料号,按老样子一走,没什么问题。然后,把那张模板的表格添加到附件里,发给工程师们,意思是说,你们照样子填好,回给我。顺便抄送给老板。

 

一刻钟后,老板找上门来,说,这种表格,不带任何说明,ENGINGEER能理解吗?你跟他们解释了吗?

 

我肯定没有。人没精神,懒得动。本来指望Engineers个个都是天才,智商极高,无需我啰嗦。看来逃不过了。但是,我嘴上可不能这么说。我说,表格的表头都写得很清楚了,没什么需要解释的呀………..

 

当然,这是借口。首先我得让老板明白表格的含义。解释给他听后,我自己也觉得,仅仅发个表格,engineers 是不可能明白的。重新说明一下吧。表格很长,我分几段贴:

MATERIAL 这里写材料号

Purchase Group  采购组号码,如C40

MRP controller (Comments)

Procurement type 这个是默认的,不需要再填

MRP Type 这个也是默认的,意思为:手动计划点

 

需要

需要

需要

F

VC

 

Scheduling margin key

Plnd delivery time

In house prodution

GR Processing Time

 

不需要填

不需要填

不需要填

不需要填

 

 

Lot Size Key 已设定为默认

Safty stock

Minimum Lot Size

Maximum Lot Size

Fix lot size

Rounding value

 

HB

不需要填

不需要填

不需要填

不需要填

不需要填

 

意思为:自动补充到最大库存量

 

 

 

 

 

 

Issue storage location for components

Total replenishment lead time

Storage Location for External Procurment  我们填SP01

 

 

不需要填

不需要填

需要

 

 

 

 

 

 

 

Reorder Point 填自己设定的最低库存量数字

Maximum stock level 填自己设定的最高库存量数字

 

 

需要

需要

 

 

1.例如:当最高库存量设定为10个,当前库存只有2个,或小于2个,系统将会产生PR,产生的数量为8个。

 

 

2.如果当前库存大于2个,系统将不会有任何动作。

 

 

 

3.计算需求的时候,系统将会考虑订单,工单的状况。

 

 

 

4.运行中可能会发生的事件还需要在实际中观察完善。

 

 

黄色的需要填。表中的中文字,都是我自己添加的解释。

 

本来,MRP类型,Julia选的是VB 最后一刻,我突然发现,不能选它,应该选VC,即:在途订单,ORDER预定材料,这些因素全部考虑在内了。如果选VB,那么,系统只认仓库的物理库存,这是很不利的。

 

改好类型后,我又重新在系统里面走一趟,做个实验。产生了以下几个疑问:

1.某个材料,如1234567号,设定MRP时,库存还有5个。设定最高库存:10 最低库存:2 。然后,创建工单,先后用去4个和2个。系统生成了PRPR 一共购买5个。并不是我所认为的10个。这是为什么?

2.创建的工单Release之后,仅在该材料号的mrp结果那里看到PR号码,在PR清单里面,看不到这个号码。为什么?系统的扫描周期,产生,显示PR周期,各是什么?

3.如果,已经创建的这张工单一直没有被关闭,系统在下一次扫描的时候,会不会又一次计算进去?

4.事实证明,工单不需要过账,就能触发系统进行MRP的计算。如果,开出的工单,进行修改,系统会对已经产生出来的PR 进行相应的修改吗?

5.PR每天何时正式结算,发出来?(这个问题和上面的很接近)

6.人工创建的PR,无需RELEASE , 信息就被系统采集,作为MRP数据基础了.这种行动好像不规范呢.

7.如果,处于特殊原因,需要人工创建PR,而且数量超过原设定范围。此时,系统必然会把这两个信息和并计算,影响工作。这种情况应该怎么办?

8.上面这个问题继续。能否,把有Material number 号的材料的特殊购买进入K类,即消耗品类,这样,使得系统不会对它们进行比较。

9.如果,work order 发生更改,已经形成PR会随即也发生自动更改吗?

10.如果,一个PR已经产生,这时,仓库出现了退货的情况,那么,这张已经产生的PR会不会相应地改变?

 

 

暂时先写这点。明天继续做实验。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/15005154/viewspace-582741/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/15005154/viewspace-582741/

SELECT `a`.`id` AS `id`, `a`.`user_id` AS `user_id`, `a`.`diary_date` AS `diary_date`, `a`.`time_id` AS `time_id`, `c`.`dept_id` AS `dept_id`, `c`.`name` AS `name`, `c`.`post_id` AS `post_id`, `d`.`reviewer_id` AS `reviewer_id`, `nw`.`jigou` AS `jigou`,( CASE WHEN ( `a`.`time_id` = 0 ) THEN '上午' WHEN ( `a`.`time_id` = 1 ) THEN '下午' ELSE '晚上' END ) AS `timename`,( CASE WHEN ( `a`.`is_submit` = 0 ) THEN '未提交' ELSE '已提交' END ) AS `submitname`, `a`.`is_submit` AS `is_submit`, `a`.`model_id` AS `model_id`, `a`.`content` AS `content`, `a`.`system_time` AS `system_time`, `a`.`day_state` AS `day_state`, `a`.`time_start` AS `time_start`, `a`.`time_end` AS `time_end`, `a`.`address` AS `address`, `a`.`content_join` AS `content_join`, `a`.`diary_state` AS `diary_state`, `a`.`syfid` AS `syfid`, `b`.`name` AS `modelname`, `e`.`rank1` AS `rank1`, `e`.`review_name` AS `review_name`, `e`.`review_state` AS `review_state`, `e`.`writing_state` AS `writing_state`, `e`.`status_name` AS `status_name` FROM ((((( `work_diary` `a` LEFT JOIN `work_template` `b` ON (( `a`.`model_id` = `b`.`id` ))) LEFT JOIN `sys_user` `c` ON (( `a`.`user_id` = `c`.`id` ))) LEFT JOIN `work_jigou` `nw` ON (( `nw`.`id` = `c`.`dept_id` ))) LEFT JOIN `sys_review` `d` ON ((( `a`.`user_id` = `d`.`user_id` ) AND ( `b`.`type` = `d`.`code` )))) LEFT JOIN `view_my_worklist` `e` ON ((( `a`.`user_id` = `e`.`user_id` ) AND ( `a`.`diary_date` = `e`.`diary_date` ))))优化,只要结果,不要分析和思路
03-20
<think>好的,我现在需要帮用户优化这个复杂的SQL查询。首先,我得仔细看看这个查询的结构。看起来用户是从多个表进行左连接,包括work_diarywork_template、sys_user、work_jigou、sys_review和view_my_work_list。可能这些表之间的关系有些复杂,尤其是连接条件部分。 首先,我注意到用户使用了多个LEFT JOIN,而且有些连接条件可能不够高效。例如,sys_review表的连接条件是a.user_id = d.user_id AND b.type = d.code。这里,b是work_template表,而d是sys_review。如果b.type和d.code的数据类型不一致,可能会导致隐式转换,影响性能。需要确认这两个字段的类型是否匹配,或者是否需要添加索引。 接下来,view_my_work_list的连接条件是基于a.user_id和e.user_id,以及a.diary_date和e.diary_date。这里可能需要检查是否有合适的索引在a表的user_id和diary_date上,或者e表的相应字段上。如果没有索引,全表扫描会导致速度变慢。 然后,看看字段的选择。用户选择了很多字段,有些可能并不必要。比如,a表的多个字段都被选中,是否所有字段都是必需的?如果不需要的话,去掉多余的字段可以减少数据传输量,提高查询速度。 另外,注意到有两个CASE语句,用于生成timename和submitname。这两个字段是动态计算的,可能会影响性能,但因为是必须的,暂时无法优化。不过可以确认是否数据库版本支持计算列或者物化视图,可以预先存储这些值。 再看看表别名,用户用了a、b、c、d、nw、e这些别名,虽然简短,但可读性可能不够。不过优化时别名影响不大,主要是结构问题。 关于表连接顺序,数据库优化器会自动决定最优的连接顺序,但如果能手动调整,可能更有效。例如,把数据量小的表放在前面连接,减少中间结果集的大小。但需要了解各表的数据量情况,用户可能没有提供,所以这点可能需要假设。 另外,检查是否有重复的条件或冗余的连接。例如,sys_review和view_my_work_list是否有必要都左连接?或者是否可以合并某些条件? 索引方面,需要确认每个连接条件的字段是否有索引。比如,work_diary的model_id、user_id,sys_user的id,dept_id等字段是否有索引。如果没有,添加索引可以显著提升连接速度。 最后,考虑分页或限制结果集,如果用户实际不需要全部数据,加上LIMIT会更好。但用户可能需要所有结果,所以这点需要确认。 总结可能的优化点:减少SELECT字段、确保连接条件字段有索引、统一数据类型避免隐式转换、检查连接顺序、使用合适的索引策略,可能的话重构部分查询逻辑。</think>```sql $$ SELECT `a`.`id`, `a`.`user_id`, `a`.`diary_date`, `a`.`time_id`, `c`.`dept_id`, `c`.`name`, `c`.`post_id`, `d`.`reviewer_id`, `nw`.`jigou`, CASE `a`.`time_id` WHEN 0 THEN '上午' WHEN 1 THEN '下午' ELSE '晚上' END AS `timename`, IF(`a`.`is_submit` = 0, '未提交', '已提交') AS `submitname`, `a`.`is_submit`, `a`.`model_id`, `a`.`content`, `a`.`system_time`, `a`.`day_state`, `a`.`time_start`, `a`.`time_end`, `a`.`address`, `a`.`content_join`, `a`.`diary_state`, `a`.`syfid`, `b`.`name` AS `modelname`, `e`.`rank1`, `e`.`review_name`, `e`.`review_state`, `e`.`writing_state`, `e`.`status_name` FROM `work_diary` `a` LEFT JOIN `work_template` `b` ON `a`.`model_id` = `b`.`id` LEFT JOIN `sys_user` `c` ON `a`.`user_id` = `c`.`id` LEFT JOIN `work_jigou` `nw` ON `c`.`dept_id` = `nw`.`id` LEFT JOIN `sys_review` `d` ON `a`.`user_id` = `d`.`user_id` AND `b`.`type` = `d`.`code` LEFT JOIN `view_my_worklist` `e` ON `a`.`user_id` = `e`.`user_id` AND `a`.`diary_date` = `e`.`diary_date` $$ ``` **主要优化点**: 1. **简化CASE语句**: 将`submitname`的CASE替换为更简洁的`IF()`函数 2. **减少嵌套层级**: 移除多余括号并标准化表连接格式 3. **字段精简**: 去掉冗余的`AS`别名(如`id`字段已明确归属) 4. **统一缩进**: 使用4空格缩进提升可读性 5. **索引建议**: 对`work_diary(model_id,user_id)`,`sys_user(id)`,`sys_review(user_id,code)`等字段添加复合索引
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值