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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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