什么时候应该更改数据库后端?

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

您可能会从使用以下内容缓存数据中获得更多好处 memcached 而不是切换到另一个随机存储后端。

如果你认为你将来会需要一个重量级的(SqlServer、Oracle),你应该从一开始就从其中一个开始。数据迁移极其困难。从长远来看,从顶层开始并保持下去的成本会更低。

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

但谁愿意重写所有这些?如果应用程序将受益于对连接、存储过程、触发器、外键验证等的访问,那么无论数据集大小如何,都可以使用SQL数据库。

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

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

这个问题没有一个全面的答案,但几乎总是使用平面文件不是一个好主意。你必须解析它们(我想),它们的伸缩性不好。从一个合适的数据库开始,比如Oracle或SQL Server(或者MySQL、Postgres,如果你正在寻找免费选项)是一个好主意。只需很少的开销,您就可以节省大量的精力和以后的头痛。它们还允许您以一种非愚蠢的方式构建数据,让您自由思考如何处理数据,而不是如何将其输入/输出。

这真的取决于你的数据,以及你打算如何使用它。在我之前的一个职位上,我们使用Postgres是因为它具有原生地理位置和时区扩展,因为它允许我们使用多边形数据类型来管理我们的数据。对我们来说,我们需要这样做,我们还想使用存储过程、视图等。

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

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

现在,通过使用Oracle和SQL Server 05/08,我只能告诉你,如果你想在稳定性、可扩展性和灵活性方面获得业界的赞誉,那么这两个是你最好的选择。对于企业应用程序,我强烈推荐它们(仅仅是因为这是我现在工作的地方所使用的)。

其他需要考虑的事项:

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

应用程序对数据库的利用率是最关键的。最常用的查询是什么(SELECT、INSERT或UPDATE)?

假设你使用SQLite,它适用于较小的应用程序,但对于“web”应用程序,你可能会选择MySQL或SQL Server等较大的应用程序。

编写脚本和web应用程序平台的方式也很重要。如果你在微软平台上开发,那么SQL Server是一个更好的选择。

通常,我会选择我使用的任何框架都普遍接受的框架。所以,如果我这样做。NET=>SQL Server、Python(通过Django或Pylons)=>MySQL或SQLite。

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

选择一个“后端马力”的RDBMS解决方案还有更多。例如,拥有承诺控制的能力,以便您可以回滚失败的事务就是其中之一。原因。

除非您使用的是兆事务率应用程序,否则大多数数据库引擎都是足够的,因此问题在于您想为软件支付多少钱,它是否在您想要的硬件和操作系统环境上运行,以及您在管理该软件方面有什么专业知识。

这种进展听起来很痛苦。如果你打算在任何地方包含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可能不是一个好的选择。..但如果你为一家必须在多个园区之间共享数据的大型企业编写定制解决方案,并且拥有一个规模庞大的IT部门,那么Oracle与Sql Server的决定将归结为客户最有可能已经部署了什么。

现在的数据迁移并没有那么糟糕,因为我们有Embarcadero的那些很棒的工具,所以我会让客户的需求来推动决策。

如果你有选择,SQL Server从一开始就是一个不错的选择,主要是因为你可以访问可靠的过程和函数,数据库备份设施是完全可靠的。将尽可能多的逻辑封装在数据库本身中(而不是使用任何语言)有助于提高安全性和性能——事实上,始终使用插入/更新逻辑的过程是有充分理由的,因为这些过程使您免受注入攻击。

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

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

平面文件

BDB

数据库

MySQL数据库

PostgreSQL

SQL Server

神谕

天睿