我正在用Python编写心理学实验。我需要在某个地方存储用户信息和分数，我需要它作为Web应用程序（并且是安全的）。
对此不太了解 - 我正在考虑XML数据库，BerkleyDB，sqlite，一个openoffice电子表格，或者我对python“shelve”库非常感兴趣。 （我的大部分信息都来自这个帖子：http://developers.slashdot.org/story/08/05/20/2150246/FOSS-Flat-File-Database
DATA：我认为我将拥有最多1000个用户。对于我必须存储的每个用户......
非常粗略估计，每个用户每天产生100次试验。所以最多每天10k数据点。它需要以这种方式运行大约3个月，所以大约1米的数据点。安全乘数2x为我提供了一个可以处理2m数据点的数据库的目标。
（（注意：我可以将试验响应数据存储为单独的数据点，或者将试验分组到不同长度的Python列表对象（用户“会话”）。后者会显着降低数据库条目数，但不是数据量。重要吗？怎么样？））
我想要一个能够（至少）工作的解决方案，直到达到这1000个用户级别。如果我的程序在该级别之外很受欢迎，那么我可以在更强大的数据库中进行一些工作模式。还重申必须能够轻松部署为Web应用程序。
除了这些基本要求之外，我只想要能够实现这一目标的最简单的事情。我很绿。
感谢您阅读
Tr3y
答案 0 :(得分：12)
SQLite当然可以处理这些数据量，它拥有非常庞大的用户群，在所有主要平台上都有一些very well known users，它快速，轻便，并且awesome GUI clients允许您浏览只需点击几下即可提取/过滤数据。
当然，SQLite无法无限扩展，但严重的性能问题只在simultaneous inserts are needed开始，我猜这是一个问题，在你预期的加载后出现了几个数量级。
我已经使用它几年了，我从来没有遇到过这个问题（虽然我使用MySQL的大型网站）。就个人而言，我发现“小。快。可靠。选择任意三个。”（这是SQLite网站上的标语）非常准确。
至于易用性 ... SQLite3 bindings（网站暂时关闭）是python标准库的一部分。 Here你可以找到一个小教程。有趣的是，简单性是SQLite的设计标准。来自here：
许多人喜欢SQLite，因为它小而快。但那些品质只是快乐的事故。用户还发现SQLite非常可靠。可靠性是简单性的结果。复杂性较低，出错的可能性较小。所以，是的，SQLite小巧，快速，可靠，但首先，SQLite力求简单。
答案 1 :(得分：6)
关于何时使用SQLite here的讨论很明显。我最喜欢的一行是：
另一种看待SQLite的方法是：SQLite不是为了取代Oracle而设计的。它旨在取代
fopen()。
在我看来，根据您的需求，SQLite是完美的。事实上，在我看来你很可能永远不会需要任何其他东西：
默认页面大小为1024字节，SQLite数据库的大小限制为2 TB（2 ^ 41字节）。
听起来你不会在任何时候拥有那么多数据。
答案 2 :(得分：0)
我会考虑MongoDB。它非常容易上手，并且是为多用户设置而构建的（与SQLite不同）。
它还有一个更简单的模型。您只需获取表单中的所有数据并将其填充到数据库中，而不是使用表格和字段。即使您的表单发生更改（oops，忘记了字段），您也不需要更改MongoDB。