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

我最初的想法是执行此命令的顺序类似于以下内容(但不一定如此，这就是为什么我要问这个问题)。

• 平面文件
• 银行
• SQLite的
• 的MySQL
• PostgreSQL的
• SQL服务器
• 甲骨文

解决方案

回答

应用程序对数据库的利用率是最关键的。主要是最常用的查询(SELECT，INSERT或者UPDATE)？

假设我们使用SQLite，它适用于较小的应用程序，但是对于" Web"应用程序，我们可能适合较大的应用程序，例如MySQL或者SQL Server。

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

回答

这不是那么容易。唯一的一般经验法则是，当当前解决方案无法跟上时，我们应该寻找另一种解决方案。这可能包括使用不同的软件(不一定按任何全球固定的顺序)，硬件或者体系结构。

使用像memcached这样的数据来缓存数据，可能会比切换到另一个随机存储后端获得更多的好处。

回答

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

平面文件

银行

SQLite的

的MySQL

PostgreSQL的

SQL服务器

甲骨文

Teradata

回答

如果我们认为自己将需要其中一种重量级工具(SqlServer，Oracle)，则应从一开始就选择其中一种。数据迁移非常困难。从长远来看，仅从顶部开始并停留在顶部，花费就会减少。

回答

通常，我会使用我所使用的任何框架通常都接受的东西。因此，如果我正在执行.NET => SQL Server，则Python(通过Django或者Pylons)=> MySQL或者SQLite。

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

回答

选择仅具有"后端功能"的RDBMS解决方案还有更多。例如，具有承诺控制能力(使我们可以回滚失败的事务)的能力就是其中之一。原因。

除非我们使用兆事务速率应用程序，否则大多数数据库引擎就足够了，因此这成为我们要为该软件支付多少费用，它是否可以在所需的硬件和操作系统环境上运行以及我们拥有什么专业知识的问题管理该软件。

回答

我认为排名过于具体。我们几乎可以从平面文件之类的东西开始创建非常小的数据集，然后从DBM之类的东西开始到更大的，不需要像SQL一样的语法的文件，然后再进入某种SQL数据库。

但是谁愿意做所有这些重写呢？如果应用程序将从连接，存储过程，触发器，外键验证等访问中受益，则无论数据集大小如何，都只需使用SQL数据库即可。

哪一个应该更多地取决于客户端的现有安装和可用的DBA技能，而不是所拥有的数据量。

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

回答

那进展听起来很痛苦。如果要在任何地方包括MS产品(特别是付费SQL Server)，则最好使用整个堆栈，因为我们只需要为其中的最后一个付费：

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

如果最初将应用程序定位于SQL Server Compact，则可以保证所有SQL代码都无需进行修改即可扩展到下一个版本。如果规模超过了SQL Server Enterprise，那么恭喜我们。这就是他们所谓的好问题。

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

回答

这个问题确实取决于情况。

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

回答

对于这个问题，还没有明确的答案，但是总是使用平面文件并不是一个好主意。我们必须解析它们(我想)，它们的伸缩性不好。从一个合适的数据库开始，例如Oracle或者SQL Server(或者MySQL，Postgres，如果我们正在寻找免费选项)，是一个好主意。只需很少的开销，以后我们就可以省去很多工作和头痛。它们还使我们能够以非愚蠢的方式来构造数据，从而使我们可以自由地考虑如何处理数据，而不是如何输入/输出数据。

回答

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

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

SQL Server长期以来一直具有4gb的数据库限制(请参阅SQL Server 2000)，但是尽管有此限制，它对于清除旧数据的中小型应用程序仍然是一个非常稳定的平台。

现在，通过使用Oracle和SQL Server 05/08，我能告诉是，如果我们希望获得稳定性，可伸缩性和灵活性的最佳选择，那么这两个是最佳选择。对于企业应用程序，我强烈推荐它们(仅因为这就是我们现在使用的工作环境)。

要考虑的其他事项：

• 语言集成(ASP.NET会话存储，角色管理等)
• 查询类型(选择，更新，删除)[虽然这更多是模式设计问题，而不是DBMS问题)
• 资料储存需求

回答

那FireBird呢？那将适合那个清单呢？

回答

并且不要忘记解决方案的"客户"也必须具备的要求。如果我们为小型公司编写商业应用程序，那么Oracle可能不是一个不错的选择……但是，如果我们为大型企业编写自定义解决方案，则该解决方案必须在多个园区之间共享数据，并且拥有规模庞大的IT部门，那么， Oracle vs Sql Server的决定将取决于客户最有可能已经部署了什么。

由于我们拥有来自Embarcadero的出色工具，因此如今的数据迁移并没有那么糟糕，因此我应该让客户的需求来驱动决策。

回答

如果可以选择SQL Server，那么从一开始就是一个不错的选择，主要是因为我们可以使用可靠的过程和功能，并且数据库备份工具是完全可靠的。在数据库本身内部尽可能多地封装逻辑(而不是使用任何语言)有助于提高安全性和性能，确实有一个很好的论点，就是始终使用插入/更新逻辑过程，因为这些过程使我们无懈可击注射攻击。

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