开元(中国)官方网站最新APP下载

　　月底进行一次盘存，系统账面有 2 样 xxx 商品报损了。我（老板）怎么知道这个东西是不是真的损坏了？还是被人以报损的名义拿走了？

　　系统里重要有个盘存的记录来记录盘存是谁在什么时候由主持的。未来真发现有什么端倪，这些记录是不是就是罪证，我（老板）要追责的。

　　在公司层面，大到财务的出入帐，小到的设备器材的领用，再到个人生活层面的电商的订单、外卖的订单，这些信息是不是都需要去记录是在 什么时候发生的这个操作，相关干系人都是谁，涉及到了什么东西？

　　以上随手举得几个例子的背后都是我们讲的这个核心概念：业务功能就是整个公司/系统的核心功能，而核心功能那就意味着这个操作本身一定要

　　现在仓库里有 xxx 商品 100 件。我（老板）怎么知道是谁在什么时间以什么价格从哪个供货商那里进的货？

　　进货功能的关注点不仅仅是商品数量的变化，数量从 50 变成了 100。它还要关注『进货功能』本身。我（老板）怎么知道采购员与供货商有 没有什么私下交易？

　　业务功能是增删改查，但是增删改查不一定是业务功能。一个系统中的操作是分三六九等的，而这些操作所涉及的表也是要分轻重缓急。 业务功能意味着系统中需要去记录这个业务操作所发生的日期时间，相关责任人，所涉及的东西，甚至是业务行为发生的地点。 所以，业务功能所涉及的表有个很明显的特征，就是表中 一定会有一个或两个和日期时间有关的字段 。 你可以通过去分析你所要实现的这个功能代表的 操作本身是否需要记录在案 来判断它是否是一个业务功能，是否是一个核心功能。

　　大家都知道做项目、写代码就是『增删改查』，这个说法指的是无论什么功能它最终落实到数据库层面都是 CRUD SQL 语句。这句话没错。 但是大家往往没意识到，『增删改查』这种说法一开始只是程序员的自我调侃，有时侯讲师为了给学生的思想松松担子，也会采用这种说法来给大 家放放松。small（当然，不排除真有讲师自己都是以为些项目就真的是单纯的增删改查）/small。 这句话普遍流传以后，给大家带来的副作用是：学生在自己去设计项目的时候，会出现为了增删改查而增删改查的情况。 例如，我设计了一张 xxx 表，为了『证明』我可以对这张表执行增删改查操作，或者说为了证明这张表的存在价值，那么我为这张表设计一套增 删改查功能来操作它，证明：你看这里有张表，我 / 你可以操作它 。 这么干类似于什么呢？你先开枪，开枪以后再画靶，最后你会发现你可以枪枪十环！ 现实中的实际情况应该是『上面这种学生思维的反向操作』：你要实现 xxx 功能，而这个功能最终落实到数据库中，实对 xxx 表进行了增删改查 操作。 不是为了增删改查而增删改查 。 诚然，任何项目的功能最后落实到数据库其实是 CRUD SQL 语句，但是，增删改查也是要分三六九等的！功能与功能之间并非绝对公平，表与 表之间也并非完全平等。这背后就是普通功能和业务功能的区别。 至于『普通功能和业务功能的区别』我们从一个看似无关的题外话说起。

　　开元体育app下载

　　就这个图书信息管理系统的这个修改功能而言谁什么时候改的这个信息其实这本身并不重要重要的是赶紧把它给我改好咯至于是张三改的还是李四改的至于是1号上午改的还是2号下午改的相较而言并不太重要因此数据库中也不会去刻意记录这些信息

　　面试官：讲讲你最近的这个项目的业务功能吧？ 小白：我的这个项目的功能是增...删...改...查... 面试官：不是，我说的是业务功能。 小白：业务功能就是增...删...改...查...呀？ 面试官：不是，业务！你们项目业务就是增删改查吗？ 小白：是啊，业务不就是增删改查啊！ 面试官心想：原来这 TMD 是业务啊？！ 面试官：好吧，你回去等通知吧。 小白开开心心回家等通知。

　　『功能一』最终是涉及到一条 udpate SQL 语句，需要去修改『图书信息表』中的某条记录的『内容简介』字段；『功能二』最终是涉及到一条 insert SQL 语句，需要去『借阅记录』表中新增一条记录。 我相信绝大多数人仅仅凭直觉就会觉得『功能二』比『功能一』要重要。为什么？ 因为 功能一的关注点并不在修改这件事情本身，而是强调的是修改的结果 。就这个图书信息管理系统的这个修改功能而言开元体育网站，谁什么时候改的这个 信息其实这本身并不重要，重要的是 赶紧把它给我改好咯 ，至于是张三改的，还是李四改的，至于是 1 号上午改的，还是 2 号下午改的，相较 而言并不太重要，因此数据库中也不会去刻意记录这些信息。 但是功能二则不同，功能二的关注点是在于『借书』这件事情上，功能二要明确去记录什么人在什么时候借走了什么书，这本书借走之后，数据库 中这种书的库存少了一本，这是毫无疑问的，但是 功能二的功能重点并不仅仅是将库存量减一 。功能二就是一个为以后『翻旧账』而准备的功 能：xxx 同学，你上次借的 yyy 书马上要超期了，你要么把书还回来，要么续借。

　　当然，如果你做的是一个医院（特别是产科）的系统，那么这个出生日期所代表的『降生』就是一个业务行为。

　　开元体育app下载

　　这里大家体会下。 第二个『假』核心表的情况是，有的系统中出于某些原因，一些表（甚至是所有表）都会有类似 added_datetime 和 last_updated_datetime 这样的 字段去记录表中的这条记录时何时新增的，最近一次修改是什么时候。 这种情况下的日期时间并不是从业务层面上所要求的去记录业务操作发生的日期时间，而是一种数据库的设计规范，人为要求。你肯定不可能就凭 这就认为整个系统中的所有表都是业务功能所操作的核心表。

　　上述的两个功能中，『借书』功能涉及到的『借阅记录表』最大的不同在于：它涉及到的需要操作的表中一定是有一个（或两个）日期时间 （date、time、datetime）类型的字段的。 因为 业务功能/核心功能需要记录『操作本身』，即，这个操作是谁，在什么时候执行的，涉及到了什么东西。 而普通功能并不太在意操作本身，更在意的是操作的执行效果，而无需记录操作本身。既然无需记录操作本身，那么自然就不在意操作发生的日期 时间。 举例几个例子大家体会下这个『日期时间』字段的价值：

　　核心表（业务功能操作的表）一定是有一个或两个与日期时间相关的字段。但是反过来，如果一个表中有与日期时间相关的字段，那它一定是核心 表吗？ 不一定。 例如，一个员工表。员工表中我们可以有一个字段去记录员工的『生日』。这个日期只是一个单纯的数据，而不是某个业务的发生时间。 如果员工表中还有一个字段是用来记录员工的『入职』日期，你仔细体会下，这个『生日日期』和『入职日期』的意义是不一样的。『入职日期』 代表着一个『入职』操作的发生时间。而员工『降生』这个操作在这个系统中可能并不是一个『业务行为』。

　　说完吵架翻旧账的话题，我们回到我们的项目和代码中普通业务，以大家都熟悉的图书管理系统为例，大家体会一下下面两个功能的区别： 功能一：

　　系统中有图书的详细信息，其中有一项是图书的『内容简介』。有一本书 xxx，它的简介比较粗略，现在我需要修改它的简介，这次要改成更 详尽一些。

　　有位 xxx 同学，他借走了一本 yyy 书开元体育网站。我需要将什么人什么时候接了什么书这个事情给记录下来。

　　人与人之间，特别是情侣夫妻之间吵架最忌讳什么？最忌讳的就是 翻旧账 。 吵架只要一翻旧账，那么就意味着这个吵架无论是因为什么原因引起的，那么接下来它一定就会脱离就事论事的范畴，往伤心伤感情的路上一路飞 驰而去。这个架一定是越吵越大，最后不欢而散。 现在我们反其道而行：如果，我要为以后吵架翻旧账做准备，那么我平时应该要注意什么？要干什么？ 答案毫无疑问，你一定要去记录 什么时候什么人说了什么话做了什么事，对我造成了多少点伤害！ 你一定要用一个小本本把伤害了你的人和事以及发生的时间都记录下来。正所谓“君子报仇，十年不晚”，这个小本本迟早会派上用场的。

　　记录在案，而记录在案就意味着它们所涉及的表中一定有日期、时间相关的字段 。 如果一个表中没有日期、时间字段，那么就意味着操作这张表的功能实际上是一个非核心功能，或者说，这个表在整个项目中的『地位』比较低， 它的存在价值是为了『辅助』核心表而存在的。 对非核心表的操作，自然就一定是普通功能干的；对核心表的操作，自然就是业务功能干的。

　　有些核心表只有一个日期时间字段，有些会有两个。这取决于这个业务行为是一个『瞬间』行为还是一个『持续性』行为。 如果业务操作是一个瞬间行为，那么表中只有一个日期时间字段去记录行为发生的日期时间。 如果业务操作是一个持续性行为，那么表中需要有两个字段去记录行为发生的起始时间和截止时间。 另外，一般的情况下，核心表通常都可以叫做：xxx 记录表。『xxx』通常是动词。 例如：进货记录表、盘存记录表、财务出帐记录表、设备领用记录表。当然，凡事不可绝对，比如，订单表就不是这个命名套路，当然你认为它也 可叫下单记录表，这也能往这个说法上套。