Django数据创建和提交

数据库针对基于集合的操作进行了优化,因此在一个集合中插入100条记录比一次插入一条记录要快。但是,当您谈论用户每次输入一个记录时,您不希望在我能想到的任何情况下将它们分组在一起。为什么?

首先,如果有一个坏记录,其他的就会失败。这将使100个用户中有99个脾气暴躁的用户(实际上是100个,但一个没有真正的理由脾气暴躁,因为他一开始就输入了糟糕的数据)。 第二,用户在输入后不会立即看到记录。同样,在将这些记录输入到相关表(如将数据输入到相关表中)之前,它们将无法对这些记录做进一步的操作。这样的延迟会让用户变得暴躁。如果用户通过电话输入客户的数据,他们在等待时会特别暴躁(我在一个呼叫中心工作,有一个速度非常慢的商业产品,相信我知道用户过去有多沮丧!) 第三,用户会继续做其他事情,并且不会意识到他们的数据是因为坏信息而被拒绝的,一点也不好。 你要等多久才能得到你设定的记录数?5秒,10分钟? 如果由于某种原因,网络连接在这段时间内丢失,用户不会丢失他们输入的数据,会发生什么情况?

你 可以 能把这样的东西拼凑在一起,但是你 真的? 不应该,因为它会破坏您的数据完整性,而这正是使用事务的关键所在。

在您建议的解决方案中,批量中任何插入的问题都会导致来自完全不同用户的所有其他插入(可能完全有效)失败。此外,用户将无法看到他们刚尝试插入的数据,因为系统正在等待执行插入操作,直到批处理满为止。

这里是一个 quick intro to transaction processing .

我认为你确实有一个误解。听起来,你把数据库看作是一种只用于某种“长期”记忆的东西。这是一个糟糕的概念;数据库是 只有 应用程序的内存。即使这不是真的,也最好假装是真的。

要更深入一点,您的应用程序有:

• 作用域内存:例如,在视图函数中定义的变量。当流离开函数时,这些都会被破坏。
• 全局:在代码最外层定义的变量。除了配置常量之外,不要将它们用于任何类型的状态,这一点非常重要。重要的是,您应该依赖于任何动态行为。否则,您将不得不与并发性作斗争 和 相互不认识的分叉进程(取决于服务器网关)。别这么做。
• 如果选择实现缓存方案,则为缓存方案。这在Django是完全可选的,有很多方法可以做到。但是,通常使用一些方案来确保即使缓存崩溃,数据库也能准确反映数据的当前状态。
• 您的本地文件系统。从设计的角度来看,大多数利用这一点的方法要么类似于缓存系统(上图),要么笨拙而脆弱。从性能的角度来看,它可能和数据库一样慢。
• 你的数据库。

所以你会发现除了数据库之外,没有太多地方可以放置你的数据。