database - 什么时候该更改数据库后端？

Question

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

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

平面文件
发展局
SQLite
MySQL
PostgreSQL
SQL 服务器
甲骨文

score 8 · Accepted Answer

这不是那么容易。唯一的一般经验法则是，当当前的解决方案无法跟上时，您应该寻找另一种解决方案。这可能包括使用不同的软件（不一定以任何全局固定顺序）、硬件或架构。

与切换到另一个随机存储后端相比，使用memcached之类的缓存数据可能会给您带来更多好处。

score 5 · Accepted Answer

如果您认为您将需要其中一个重量级（SqlServer、Oracle），那么您应该从一开始就使用其中一个。数据迁移非常困难。从长远来看，从顶部开始并留在那里会花费更少。

score 2 · Accepted Answer

我认为您的排名过于具体。对于非常小的数据集，您几乎可以从平面文件等开始，对于不需要类似 SQL 语法的稍大的数据集，可以使用 DBM 之类的东西，然后再使用某种 SQL 数据库。

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

哪一个应该更多地取决于客户的现有安装以及可用的 DBA 技能，而不是您持有的数据量。

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

score 1 · Accepted Answer

对此没有一概而论的答案，但几乎总是，使用平面文件不是一个好主意。您必须解析它们（我想）并且它们不能很好地扩展。从合适的数据库开始，如 Oracle 或 SQL Server（或 MySQL、Postgres，如果您正在寻找免费选项）是一个好主意。只需很少的开销，您就可以在以后省去很多精力和头痛。它们还允许您以不愚蠢的方式构建数据，让您可以自由地思考您将如何处理数据，而不是如何输入/输出数据。

score 1 · Accepted Answer

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

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

很长一段时间以来，SQL Server 都有 4gb 的数据库限制（请参阅 SQL Server 2000），但尽管有此限制，但对于清除旧数据的中小型应用程序来说，它仍然是一个非常稳定的平台。

现在，从使用 Oracle 和 SQL Server 05/08 开始，我只能告诉你，如果你想要最好的稳定性、可扩展性和灵活性，那么这两个是你最好的选择。对于企业应用程序，我强烈推荐它们（仅仅是因为这是我们现在工作的地方）。

其他需要考虑的事项：

语言集成（ASP.NET 会话存储、角色管理等）
查询类型（选择、更新、删除）[虽然这更多是模式设计问题，而不是 DBMS 问题）
数据存储要求

score 0 · Accepted Answer

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

假设您使用 SQLite，它适用于较小的应用程序，但对于“Web”应用程序，您可能会使用更大的应用程序，例如 MySQL 或 SQL Server。

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

score 0 · Accepted Answer

通常，我会使用我使用的任何框架普遍接受的内容。所以，如果我在做 .NET => SQL Server、Python（通过 Django 或 Pylons）=> MySQL 或 SQLite。

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

score 0 · Accepted Answer

选择仅“后端马力”的 RDBMS 解决方案还有更多。例如，具有提交控制的能力，因此您可以回滚失败的事务，这就是其中之一。原因。

除非您使用的是超大交易率应用程序，否则大多数数据库引擎就足够了 - 所以问题在于您想为软件支付多少费用，它是否在您想要的硬件和操作系统环境上运行，以及您拥有什么专业知识在管理该软件时。

score 0 · Accepted Answer

这种进展听起来很痛苦。如果您要在任何地方包含 MS 产品（尤其是付费 SQL Server），您也可以使用整个堆栈，因为您只需为其中的最后一个付费：

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

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

另外：返回并查看 SO 播客。我相信他们简短地谈到了这一点。

score 0 · Accepted Answer

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

如果您可以控制要部署到的服务器并且可以安装所需的任何服务，那么安装 MySql 或 MSSQL Express 服务器并针对现有数据库框架进行编码与针对平面文件结构进行编码的时间是不值得的的考虑。

score 0 · Accepted Answer

0

火鸟呢？那将在哪里适合该列表？

于 2008-09-16T16:53:01.710 回答

score 0 · Accepted Answer

并且不要忘记您的解决方案的“客户”也必须具备的要求。如果您为小公司编写商业应用程序，那么 Oracle 可能不是一个好的选择... Oracle 与 Sql Server 的决定将归结为客户最有可能已经部署了什么。

现在的数据迁移并没有那么糟糕，因为我们拥有来自 Embarcadero 的那些出色工具，所以我宁愿让客户需求驱动决策。

score 0 · Accepted Answer

如果您有选项，SQL Server 是一个不错的选择，主要是因为您可以访问可靠的过程和功能，并且数据库备份工具是完全可靠的。尽可能多地在数据库本身中包含逻辑（而不是使用您使用的任何语言）有助于安全性和性能 - 确实有一个很好的论据可以始终使用插入/更新逻辑的过程，因为这些使您对注入攻击无懈可击。

如果我可以选择，我唯一会优先考虑 MySQL 的情况是使用一个主要用于读取访问的大型、相当简单的数据库。这并不是要谴责最近已经显着改进的 MySQL，如果我没有选择，我很乐意使用，但是对于具有更新/插入活动的更复杂的系统，MSSQL 通常是更好的选择。

score -2 · Accepted Answer

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

平面文件

发展局

SQLite

MySQL

PostgreSQL

SQL 服务器

甲骨文

太极数据

database - 什么时候该更改数据库后端？

14 回答 14

Related

Reference