2009-11-19 75 views
2

我想知道使用数据库的权衡和其他选项是什么?另外,哪些问题不适合数据库?数据库的选择?

我关心关系数据库。

+0

像Facebook,Twitter,Wikipedia等Web应用程序不适合使用您所知道的数据库。对于相关文章,我建议你看看:http://highscalability.com/ – 2009-11-19 07:40:04

+0

这三个实际上都是由MySQL运行的。 – 2009-11-19 07:49:30

+0

你应该在你的问题中更好地定义术语“数据库”。 – 2009-11-19 07:49:57

回答

5

数据库的概念是非常广泛的。我将在这里介绍的内容做一些简化。

对于某些任务,最常见的数据库是关系数据库。它是基于关系模型的数据库。关系模型假设您以行的形式描述数据,属于表中每个表具有给定列数和固定列数的表。您以“每行”为基础提交数据,这意味着您必须在包含与您表的所有列相关的数据的单个镜头中提供一行。每个提交的行通常会获得一个在表级别唯一的标识符,有时在数据库级别。您可以在关系数据库中的实体之间创建关系,例如通过说表中的给定单元格必须引用另一个表的行,以保持所谓的“参照完整性”。

这个模型运行良好,但它不是唯一一个。在某些情况下,数据更好地组织为一棵树。文件系统是一个分层数据库。从一个根开始,并且所有东西都在这个根下面,像结构树一样。另一个模型是关键/值对。 Sleepycat BDB基本上是一个关键/价值实体的商店。

LDAP是另一个具有两个优点的数据库:存储相当通用的数据,它是按设计分布的,并且是为阅读而优化的。

图形数据库和三重存储允许您存储图形并执行同构搜索。如果你有一个非常通用的数据集,通常需要这个数据集,这个数据集可以包含对你的实体的广泛描述,如此广泛,基本上是未知的。这与关系模型完全相反,在这种模型中,用一组非常精确的列创建表,并且知道每列将包含哪些内容。

也存在一些基于关系列的数据库。不要逐行提交数据,而是按整列提交它们。

因此,要回答你的问题:数据库是一种存储数据的方法。从技术上讲,即使是一个文本文件也是一个数据库,虽然不是特别好的一个。数据库背后的模型选择主要与您的应用程序的典型需求相关。

将答案设置为CW,因为我可能会说一些严格不正确的东西。随意编辑。

1

这是一个相当宽泛的问题,但数据库非常适合管理relational data。替代品几乎总是意味着设计你自己的数据存储和检索引擎,对于大多数标准/小型应用程序来说这是不值得的。

不适合数据库的典型场景是大量数据的存储,这些数据被组织为相对较少的逻辑文件,在这种情况下,简单的类似文件系统的系统就足够了。

0
  • 对于搜索应用全文搜索引擎(其中一些被整合到传统的DBMS,但其中一些是没有),可以是一个很好的选择,同时允许更多的功能(各种语言意识,具有半结构化数据的能力,排名......)以及更好的表现。

  • 另外,我在哪里见过配置数据存储在数据库应用中,虽然这是有道理的在某些情况下,使用纯文本文件(或YAML,XML和等)和装载在初始化过程中的基础对象可能是优选的,这是由于这种替代方案的自包含性质以及易于修改和复制这样的文件。

  • 平面日志文件,可以是一个很好的选择,记录到DBMS,这取决于过程的使用。

这表示,在过去的10年左右的时间,在DBMS系统,在一般情况下,增加了许多功能,以帮助他们处理不同形式的数据和不同的搜索功能(恩:全文检索提到脱颖而出,XML,BLOB的智能存储/处理,强大的用户定义函数等),这使得它们更通用,因此是相当普遍的服务。 他们的实力主要依靠关系数据,但是

0

如果您有要存储和查询的数据,请使用数据库。

从技术上讲,大多数东西都适用于数据库。计算机用于处理数据,数据库用于存储它们。

唯一要考虑的是成本。部署成本,维护成本,时间投入,但它通常是值得的。

如果你只需要存储非常简单的数据,平面文件将是一个替代(文本文件)。

注意:您使用的是通用术语“数据库”,但这些术语有许多不同的类型和实现。

1

不要忘记看看NOSQL数据库。这是非常新的技术,非常适合在关系数据库中不适合/不适合的东西。

希望这会有所帮助。

问候,

Sebastiaan