×

Loading...

《逻辑这个东西》 - 一点工作上的闲话,一点小感慨,有点说不清是什么

​​​​​​​

逻辑这个东西

2021-06-16 非非


昨天对测试结果有疑义,发现之前和程序开发员讨论的ERP系统数据采集方式他并没有彻底理解。自己也是码农出身,就让他把code发过来看,一看发现query条件写反了而且低效,好笑又无奈,知道他会绕很久就写了code发过去让他照做,今天果然还是不太懂的样子。


简单解释一下情况:系统有两个table记录月物料库存,一个是现在库存,一个是历史数据。历史数据只有在库存有变化时才会生成。举例来说:2021年1月物料库存为100KG,2021年2月消耗新进物料后为200KG,那么就会生成一条2021-01 100KG的历史记录,如果2月到现在都没有变化那么历史数据最新的就只是2021年一月的。要求是生成每月月初和月末库存的报表。想想老外大叔程序员的数理理解力,昨天甚至还列举了列子:

如果求证2021年3月末库存

历史数据: 2021-01 100KG, 2021-04 200KG, 那么就是200KG

历史数据: 2021-01 100KG, 2021-03 50KG,2021-04 200KG 那么就是50KG

历史数据: 没有任何等于或晚于 2021-03的记录,就用现在库存

2021年3月月初库存就等于2021年2月月末库存。


晚饭时给上高中的女儿出这道题,告诉她2月份家里有3袋米,6月份现在有2袋米,历史数据的生成如上规则,问她4月份家里该有多少袋米?这可难倒了公主,一顿无厘头的乱猜。我把答案给了又解释的半天,最后变成讨论规则的合理性了。我开始解释为什么系统用这样的规则呢,大概是当年硬件存储昂贵,所以没有必要的记录就俭省了,没有用一月一计的方式,这也更符合Transactional DB的原则,不是Analytical DB的做法,不过确实增加了生成报表运算的量。现行条件下可能不会这样设计了,谁还在乎那点空间啊,但是数据多了还是会影响performance啊,index啊,扯远了。


这件事让我再次明白逻辑这个东西吧,明明白白的就是能把人绕晕,有的是因为固有的印象覆盖了真相,有的是因为畏惧繁杂而不去剥丝抽茧,有的是鲁莽无脑揪着线团乱扯。那些脑筋急转弯都是让人打破常规开启思路,这个远远不算吧,只是当年设计系统的人的一点小心思就迷惑了这一众啊。

:


Sign in and Reply
Modify
Report

Replies, comments and Discussions:

  • 工作学习 / 学科技术 / 《逻辑这个东西》 - 一点工作上的闲话,一点小感慨,有点说不清是什么 +3
    • 虽然不是很懂,但觉得很有道理,大赞! +1
      • 能看穿现象的大神! +1
    • 原来你能文能武啊,果然是才女,佩服! +3
      • 我有时能抖点小机灵😃😃😃 +1
    • 感觉很绕啊,虽然没看懂,感觉楼主的工作挺稳,一般新人搞不定。牛人就这样,都进入了不用思考的境地,走个神或者同时看电影也不影响干活 +1
      • 有这么绕吗,看例子就很明白了啊。绕就绕在历史的月份却不能参考之前的历史,想想那大叔就是卡这了。 +2
        • 有一个关键点没说清楚,比如你说X月份的数据,这个数据是X月初的数据还是X月末的数据?当然我猜测是月末的数据
          • 要求是月初和月末都要,不过月初= 前一个月末,只要会算月末就好。数据是月末的。
            • 假定六月末你银行存款是50万,第二天你中了六合彩,银行存款突然变成了5000千万。不知道你这个月初=前一个月末是什么逻辑?银行可以按你这个逻辑把你中六合彩的钱转出去,你愿意吗?
    • 用六月份的数据两袋米。答案对吗? +1
      • 对,你是个明白人儿,给颗小星星!😁😁😁 +1
    • 其实这是一个常见的设计模式,event sourcing。简化来说,你只需要存贮 historical changed event,相当于 take 一个 snapshot,然后任何一个时间点的 “current value” 就是那个时间点之前最后那个 value。 +1
      • 明白人还是一大堆吗,就是这么个事。 +3
        • 所以你只需要给他提几个关键字:snapshot, at a point in time, previous state 他就应该明白了。
          • 嗯,他会想明白的。
    • 要说是 a set of rules 还说得过去,称为逻辑有些牵强,毕竟没有 validation 的步骤。
      • 我也是想说只见规则没见逻辑。
      • 说逻辑不是说课题本身而是思维方式。逻辑性的思维方式。不过标题借得有点大😘
      • 呵呵,同感(#13848497@0),说了半天,其实那同事是没明白“规则”,而不是什么逻辑.....
    • 你们系统设计有问题。你们采用的模式通常是用在系统日志做audit。对于ERP查询,需要多一列,这样每一行都有起始和终止的时间,查询的开销会大幅降低。参见
      • 感谢真的把这当成技术文讨论了,这是个成熟的ERP大佬系统,我们只能根据自己需要做点customization,只是提取数据供给另一个做分析的系统。
    • 就是逻辑建立在一个规则上,思维要在这个规则上逻辑展开。当思维不适应这个规则时,逻辑就不见了,而且思维容易固化。
      • 思维固化,说得好。
    • 嗯,这是常见的event driving,就是每当有数据变化,触发一个event,把变化的数据写入历史table,根据一个已知时间点的库存amount,加减后面的数据就能得出任意月份的库存;挺有意思
    • 没看懂你的逻辑,怎么可以用1月,2月的和四月的库存得出三月份的库存?三月可能你们家来了一大堆客人,月末是零库存,4月份你听说大米要大涨价,你一下囤了10袋大米,吃了两袋,还有八袋,所以我认为你这个样例有问题,据此编程得不出合理结论。 +1
      • 看来你是真没明白…
        • 我是不想装明白!
          • 呵呵,你就没明白所谓的历史数据是干嘛的。
      • "库存"在这里你就当只是借用一个名词,别去死抠它的精确意思,具体是多少“库存”按规则来决定......重要的是明白那“规则”是咋定的.....
        • 你要把规则定成每月的进出都是固定的,那会计都不用了,小学毕业的都算得出来,前月月末库存等于下月月初的库存符合什么逻辑?货车司机很可能在月初第一天增加一大堆库存,难得仓管员不记录?
          • 记录又能咋地?定下了规则就按规则来办,这就是现实世界...搞IT的脑袋里充满太多的软硬件知识,如果对现实问题或运作系统的描述语境不够清楚,就容易糊涂,其实是对语言/语境的理解问题不是什么技术问题...
            • 讲逻辑就不要自毁逻辑,一点都讲不通的逻辑,还什么狗屁逻辑?
              • 俺都反复讲了,首先搞清楚人家所说的库存量是如何规定和计入/归属的,然后处理逻辑自然就有了,帖题中那“同事”其实没搞清楚的是这个规定,而不是什么逻辑....
              • 大哥,你绕进去了,一号的库存不是月初的库存呀。
          • 月末是终点,月初是起点,按同一个时间点算,不同了才过瘾呢。
            • 如果非要抠,那得详细具体的说明是月末的几点几分几秒,月初是当日的几点几分几秒,否则没法操作或写code的,一有灰色时段就乱套了.....
              • 就是同一个时间点呀,该时间点的库存既是终止月的月末值,也是起始月的月初值。
      • “规则” 是,如果库存有变化,会有一条记录。根据这个“规则”,任何一个时间点的库存,就看之前的最后那条记录。三月份的库存 == 二月份的记录说明之间库存没有变化。
    • 在俺看来,感觉讲的应该不是对处理流程的逻辑概念,更像是讲如何定义此“库存量”的规则(rules)....先有了规则,然后才有如何对数据进行处理的逻辑....规则若不够清楚,谈何逻辑?呵呵.... +3