讨论一下数据库中的临时表(非数据库自带功能临时表)

byunting 发布于 2013年12月08日
无人欣赏。

之前公司做ERP软件的。

在软件中只要涉及到流程性的操作,所涉及的表都要再加临时表。

何为临时表?比如说表T_User,那么临时表就是T_Temp_User。表结构直接复制过来,把一切约束去除,并且添加操作员和操作时间字段。

在进行某个流程操作,比如说修改(添加)样品单,系统并不直接操作真实表,而是从数据库中将真实表的数据copy到临时表,操作临时表得数据,操作完成再更新到真实表当中。

疑问:

  1. 之前不理解为什么要这样做,老大说带宽问题,不规范的小厂网络有时候提供给ERP软件用的带宽会低到5K以下,如果一个业务逻辑20-30张表的内容全部传到软件中会有带宽不足的问题。我觉得带宽也不是大问题吧,因为如果用延迟加载的话跟临时表是一样的带宽流量。

  2. 每张真实表对应一张临时表,带来维护上的问题,真实表修改添加的字段,临时表都要加,有时候会变得不容易维护。

  3. 从临时表更新到真实表其实是非常繁琐的,更新流程如下: (1)从真实表里面删除临时表里面被删除的记录 (2)更新临时表里面被更新的记录 (3)添加临时表里面新添加的记录。

     里面细节还很多,这些都是用存储过程来完成,存储过程也写得特别长。由于有临时表,原本很多应该在本地完成的逻辑,也放到存储过程里面来执行,大家都知道存储过程比较不那么直观,不容易理解,而且由于逻辑分离,导致开发上的一些困难。
    

你们公司做开发用临时表吗?用存储过程来写业务逻辑吗?

共4条回复
灵感之源 回复于 2013年12月09日

我们的逻辑都封装到存储过程,因为逻辑都复杂,不是一句简单的CRUD就可以实现。

你说的临时表是针对当前用户的吗?

临时表只复制跟该用户相关的业务数据吗?

我们的业务系统也非常复杂,存储过程里用了大量临时表,但业务完成,临时表也会销毁,不会为某用户单独实现临时表做CRUD。譬如要取数据运算复杂业务逻辑,先放要用到的数据到临时表,再运算,返回结果,临时表马上销毁。

但你所说临时表则是一直存在的,不会因为业务完成而删除。

所以,你说的临时表,应该是staging性质。譬如我们的业务系统要导入数据,目标表有几十亿记录,我们不可能直接对目标进行存在更新不存在添加,因为业务逻辑要大量运算,所以放staging表,所有操作完成,一次性合并到目标。

理论上,视乎数据大小和具体数据库系统,临时表或放内存或放物理表,都是典型的空间换取时间。只有实际测试性能才知道是否值得。

最后,你头头说的带宽理由不正确,无论是否使用临时表,都应该只返回实际所需数据,总不可能把表所有记录都返回吧?

贵人 回复于 2013年12月09日

我肿么觉得你老大的说辞就是他自己也不知道啥原因,又要让你觉得他比你厉害,所以,找一个让你不能追根问底的说法呢?

akunamotata 回复于 2013年12月09日

感觉你所谓的临时表不是临时表了,而是一个cache表,再说临时表的意义在于使用完即销毁,没有维护更新一说。

byunting 回复于 2013年12月09日

1楼 @灵感之源 临时表有字段标志 哪个用户和什么时间进行的操作

不能这样说吧,比如说用户A操作订单AA,那么将订单AA中所有的相关数据都复制到各自对应的临时表。然后用户每次操作都会传送用户ID和时间来标志对应的数据。因为不同用户临时数据都是放到临时表的。

你们的临时表应该是像SqlServer中的#Temp这样创建的临时表。我们的不是,其实我们的临时表跟真实表对于数据库来讲并无不同,只是程序员逻辑上把它当做临时表来用。

其实很简单,当用户操作订单AA,因为订单AA非常复杂,下面可能连着十几张表,所以把订单AA下面所有表连着外键的数据都一并复制到临时表,然后用户的操作就都是在临时表做改变,等用户点保存并退出后再同真实表做更新操作。

比如用户对一张订单做操作,用户临时做的改变要反映到真实表吗?这样就没办法撤销了,不过如果反映到临时表就相当于有后悔药,取消不保存的话就可以相当于什么也没做。这也许是临时表最大的用途吧。

其实我想把数据库中所有的相关数据全部down到程序中的Model里面,临时操作反映到Model应该也可以。

登录 或者 注册
相关帖子