何时该更改数据库后端？

Question

当存储Web应用程序数据以知道应该使用哪个数据库后端时，是否遵循一般的经验法则？每天点击次数，数据行数或其他指标是我在选择时应该考虑的吗？

我最初的想法是，这样的顺序看起来像下面的（但不一定，这就是为什么我问这个问题）。

1. 平面文件
2. BDB
3. SQLite的
4. MySQL的
5. PostgreSQL的
6. SQL服务器
7. 甲骨文

Answer 1

这并不那么容易。唯一的一般经验法则是当你现在无法跟上时你应该寻找另一种解决方案。这可能包括使用不同的软件（不一定以全球固定的顺序），硬件或体系结构。

使用类似memcached的缓存数据可能会比切换到另一个随机存储后端更有好处。

Answer 2

数据库您的应用程序的使用率是最关键的人。主要是哪些查询最常用（SELECT，INSERT或UPDATE）？

说如果你使用SQLite，它适用于较小的应用程序，但对于“web”应用程序，你可能是一个更大的应用程序，如MySQL或SQL Server。

您编写脚本和Web应用程序平台的方式也很重要。如果您正在Microsoft平台上开发，那么SQL Server是更好的选择。

Answer 3

我认为你的清单是主观的，但我会玩你的游戏。

平面文件

BDB

SQLite的

MySQL的

PostgreSQL的

SQL服务器

甲骨文

Teradata

Answer 4

如果您认为您将需要其中一个重量级人员（SqlServer，Oracle），那么您应该从开始之一开始。数据迁移非常困难。从长远来看，只需从顶部开始并呆在那里，就会降低成本。

Answer 5

通常情况下，我会使用我正在使用的任何框架通常接受的内容。因此，如果我在.NET中执行SQL Server，Python（通过Django或Pylons）=> MySQL或SQLite。

虽然我几乎从不使用平面文件。

Answer 6

还有更多选择只是“后端马力”的RDBMS解决方案。例如，拥有承诺控制的能力，因此您可以回滚失败的交易。原因。

除非您处于megatransaction rate应用程序中，否则大多数数据库引擎都已足够 - 因此它会成为您想要为软件支付多少费用的问题，无论它是否在所需的硬件和操作系统环境中运行，以及你在管理软件方面有什么专长。

Answer 7

我认为你的排名过于具体。对于非常小的数据集，您几乎可以从平面文件等开始，然后转到类似DBM的操作，稍微大一些，不需要类似SQL的语法，然后再转到某种SQL数据库。

但谁愿意做所有重写？如果应用程序将受益于访问连接，存储过程，触发器，外键验证等 - 只需使用SQL数据库，而不考虑数据集的大小。

哪一个应该更多地依赖于客户端的现有安装以及可用的数据库管理员技能，而不是您掌握的数据量。

换句话说，数据库的大小远非唯一的考虑因素，也许不是最重要的。

Answer 8

这种进展听起来很痛苦。如果你要包括MS产品（特别是需要付费的SQL服务器）中有没有什么地方，你不妨使用整个堆栈，因为你只需要支付在过去的这些：

SQL Server Compact -> SQL Server Express -> SQL Server Enterprise (clustered). 

如果您最初将您的应用程序定位于SQL Server Compact，那么您的所有SQL代码都可以保证在不修改的情况下扩展到下一个版本。如果你比SQL Server Enterprise更大，那么恭喜你。这就是他们所说的好的问题。

另外：回去检查SO播客。我相信他们简单地谈到了这一点。

Answer 9

这个问题真的取决于你的情况。

如果你有过要部署到服务器控件，你可以安装你需要的任何服务，那么时间的安装MySQL或MSSQL Express服务器和代码对现有的数据库架构VERSUS编码针对平面文件结构不值得考虑的努力。

Answer 10

对此没有一揽子答案，但总是使用平面文件不是一个好主意。你必须解析他们（我想），他们不能很好地扩展。从适当的数据库开始，如Oracle或SQL Server（或MySQL，如果您正在寻找免费选项的话，Postgres）是一个好主意。对于很少的开销，您将在以后节省很多精力和头痛。它们还允许您以非愚蠢的方式构建您的数据，让您可以自由地思考您将如何处理数据，而不是您将如何处理数据。

Answer 11

这实际上取决于您的数据，以及您打算如何使用它。在我以前的职位之一，我们使用Postgres由于本地地理位置和时区扩展，因为它允许我们使用多边形数据类型管理我们的数据。对我们来说，我们需要这样做，我们也想使用存储过程，视图等。

现在，我工作的另一个地方是使用MySQL，只是因为数据是规范化的，标准的逐行数据。

很久以来，SQL Server有4GB的数据库限制（请参阅SQL Server 2000），但尽管存在此限制，但它仍然是清除旧数据的中小型应用程序的非常稳定的平台。

现在，从与Oracle和SQL Server 05/08的合作中，我可以告诉你的是，如果你想让稳定性，可伸缩性和灵活性得到丰厚的收获，那么这两个是你最好的选择。对于企业应用程序，我强烈建议他们（仅仅因为这就是我们现在工作的地方）。

其他的事情要考虑：

• 语言集成（ASP.NET会话存储，角色管理等）
• 查询类型（SELECT，UPDATE，DELETE）虽然这更多的是一种模式的设计问题，而不是一个DBMS问题）
• 数据存储需求

Answer 12

约火鸟什么？那么适合那个名单？

Answer 13

并且不要忘记您的解决方案的“客户”必须具备的要求。如果你为小公司编写商业应用程序，那么Oracle可能不是一个好的选择......但是如果你为一个必须在多个校区之间共享数据的大型企业编写一个定制的解决方案，并且拥有一个好的IT部门，那么Oracle与Sql Server的决定将归结为客户最可能已经部署的内容。

现在的数据迁移并没有那么糟，因为我们有Embarcadero提供的那些优秀工具，所以我会让客户需要推动这个决定。

Answer 14

如果您有选择，SQL Server是go这个词的不错选择，主要是因为您可以访问可靠的程序和功能，并且数据库备份设施完全可靠。在数据库本身（而不是您使用的任何语言）中尽可能多地包装逻辑，这有助于提高安全性和性能 - 实际上，为插入/更新逻辑始终使用过程提供了一个很好的参数，因为它们使您不受注射攻击。

如果我有选择，那么我认为MySQL优先选择一个大型的，相当简单的数据库主要用于读取访问。这不是为了贬低MySQL，它已经有了明显的改进，如果我没有选择，我会很高兴地使用它，但是对于更复杂的系统来说，更新/插入活动通常是MSSQL的最佳选择。