数据库替代方案？

Question

我想知道使用数据库的权衡以及其他选择是什么？另外，哪些问题不适合数据库？

我关心关系数据库。

Answer 1

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

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

Answer 2

不要忘记查看一下 NOSQL 数据库。这是一项相当新的技术，非常适合关系数据库中不适合/无法扩展的内容。

Answer 3

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

从技术上讲，大多数东西都适合数据库。计算机是用来处理数据的，数据库是用来存储数据的。

唯一需要考虑的是成本。部署成本、维护成本、时间投入，但通常都是值得的。

如果您只需要存储非常简单的数据，平面文件将是一个替代方案（文本文件）。

注意：您使用了通用术语“数据库”，但它们有许多不同的类型和实现。

Answer 4

• 对于搜索应用程序，全文搜索引擎（其中一些集成到传统的 DBMS，但其中一些则没有） ，可能是一个很好的选择，它允许更多的功能（各种语言感知、半结构化数据的能力、排名......）以及更好的性能。

• 此外，我还见过一些应用程序将配置数据存储在数据库中，虽然这在某些情况下是有意义的，但使用纯文本文件< /strong>（或 YAML、XML 等）并在初始化期间加载底层对象可能更可取，因为这种替代方案具有自包含的性质，并且易于修改和复制此类文件。

• 平面日志文件可以是记录到 DBMS 的一个很好的替代方案，当然具体取决于使用情况。

也就是说，在过去 10 年左右的时间里，DBMS 系统总体上添加了许多功能，以帮助它们处理不同形式的数据和不同的搜索功能（例如：前面提到的全文搜索、XML、智能存储/处理BLOB、强大的用户定义函数等）这使得它们更加通用，因此是一项相当普遍的服务。 然而，他们的优势仍然主要在于关系数据。

Answer 5

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

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

该模型运行良好，但它并不是唯一的模型。在某些情况下，数据可以更好地组织为树。文件系统是一个分层数据库。从根开始，一切都在这个根下，形成树状结构。另一个模型是键/值对。 Sleepycat BDB 基本上是键/值实体的存储。

LDAP 是另一个数据库，它有两个优点：存储相当通用的数据，按设计进行分布式，并且针对读取进行了优化。

图数据库和三元组存储允许您存储图并执行同构搜索。如果您有一个非常通用的数据集，可以包含对实体的广泛描述（如此广泛以至于基本上是未知的），那么通常需要这样做。这与关系模型明显相反，在关系模型中，您使用一组非常精确的列创建表，并且您知道每列将包含什么。

还存在一些基于列的关系数据库。您不是按行提交数据，而是按整列提交数据。

所以，回答你的问题：数据库是一种存储数据的方法。从技术上讲，即使文本文件也是一个数据库，尽管不是一个特别好的数据库。数据库背后模型的选择主要与应用程序的典型需求相关。

将答案设置为 CW，因为我可能说的是严格不正确的事情。请随意编辑。