讨论一下数据库中的临时表（非数据库自带功能临时表）
由 byunting 发布于 2013年12月08日无人欣赏。
之前公司做ERP软件的。
在软件中只要涉及到流程性的操作，所涉及的表都要再加临时表。
何为临时表？比如说表T_User,那么临时表就是T_Temp_User。表结构直接复制过来，把一切约束去除，并且添加操作员和操作时间字段。
在进行某个流程操作，比如说修改（添加）样品单，系统并不直接操作真实表，而是从数据库中将真实表的数据copy到临时表，操作临时表得数据，操作完成再更新到真实表当中。
疑问：
之前不理解为什么要这样做，老大说带宽问题，不规范的小厂网络有时候提供给ERP软件用的带宽会低到5K以下，如果一个业务逻辑20-30张表的内容全部传到软件中会有带宽不足的问题。我觉得带宽也不是大问题吧，因为如果用延迟加载的话跟临时表是一样的带宽流量。
每张真实表对应一张临时表，带来维护上的问题，真实表修改添加的字段，临时表都要加，有时候会变得不容易维护。
从临时表更新到真实表其实是非常繁琐的，更新流程如下： （1）从真实表里面删除临时表里面被删除的记录 （2）更新临时表里面被更新的记录 （3）添加临时表里面新添加的记录。
里面细节还很多，这些都是用存储过程来完成，存储过程也写得特别长。由于有临时表，原本很多应该在本地完成的逻辑，也放到存储过程里面来执行，大家都知道存储过程比较不那么直观，不容易理解，而且由于逻辑分离，导致开发上的一些困难。
你们公司做开发用临时表吗？用存储过程来写业务逻辑吗？
我们的逻辑都封装到存储过程，因为逻辑都复杂，不是一句简单的CRUD就可以实现。
你说的临时表是针对当前用户的吗？
临时表只复制跟该用户相关的业务数据吗？
我们的业务系统也非常复杂，存储过程里用了大量临时表，但业务完成，临时表也会销毁，不会为某用户单独实现临时表做CRUD。譬如要取数据运算复杂业务逻辑，先放要用到的数据到临时表，再运算，返回结果，临时表马上销毁。
但你所说临时表则是一直存在的，不会因为业务完成而删除。
所以，你说的临时表，应该是staging性质。譬如我们的业务系统要导入数据，目标表有几十亿记录，我们不可能直接对目标进行存在更新不存在添加，因为业务逻辑要大量运算，所以放staging表，所有操作完成，一次性合并到目标。
理论上，视乎数据大小和具体数据库系统，临时表或放内存或放物理表，都是典型的空间换取时间。只有实际测试性能才知道是否值得。
最后，你头头说的带宽理由不正确，无论是否使用临时表，都应该只返回实际所需数据，总不可能把表所有记录都返回吧？
1楼 @灵感之源 临时表有字段标志 哪个用户和什么时间进行的操作
不能这样说吧，比如说用户A操作订单AA，那么将订单AA中所有的相关数据都复制到各自对应的临时表。然后用户每次操作都会传送用户ID和时间来标志对应的数据。因为不同用户临时数据都是放到临时表的。
你们的临时表应该是像SqlServer中的#Temp这样创建的临时表。我们的不是，其实我们的临时表跟真实表对于数据库来讲并无不同，只是程序员逻辑上把它当做临时表来用。
其实很简单，当用户操作订单AA，因为订单AA非常复杂，下面可能连着十几张表，所以把订单AA下面所有表连着外键的数据都一并复制到临时表，然后用户的操作就都是在临时表做改变，等用户点保存并退出后再同真实表做更新操作。
比如用户对一张订单做操作，用户临时做的改变要反映到真实表吗？这样就没办法撤销了，不过如果反映到临时表就相当于有后悔药，取消不保存的话就可以相当于什么也没做。这也许是临时表最大的用途吧。
其实我想把数据库中所有的相关数据全部down到程序中的Model里面，临时操作反映到Model应该也可以。