事件数据库的关系数据库与非关系数据库

Question

我试图找出 SQL 或非 SQL 解决方案是否更适合创建事件数据库。我正在创建一个票务系统，类似于票务主。我知道对于任何一种数据库类型的存储都是简单的部分。决定因素是以下查询的性能：

• 在特定日期范围内按位置选择事件。
• 选择给定位置（城市、城镇等）的所有事件，按日期排序。
• 在特定日期范围内、特定位置内按关键字搜索事件。

事件基本上有 ID、NAME、LOCATION、VENUE、START DATE、END DATE

在关系模式中，我会有一个 EVENTS 表，一个用于单独存储日期的 DATES 表，因为事件可以发生在多个日期并且它们是可重复的，以及一个 VENUES 表，可以从中获取事件位置（国家、城市等）交叉引用。

我没有使用 no-SQL 数据库的经验，因此如果您投票支持 no-SQL，请建议您如何看待“架构”的组织方式以及哪个特定的数据库。

我希望这个问题足够具体。查询性能是决定性因素。

经过进一步考虑，我意识到这个问题更适合提炼出日期/时间函数的可用性，这些函数可以促进快速日期范围查询。我知道 MySQL 和 PostgreSQL 有这样的功能。在这一点上，PostgreSQL 在语法方面甚至看起来更好一些。我不知道 NoSQL 解决方案必须为此提供什么。

我知道系统当然可以在关系数据库中轻松建模。我也知道每个 no-sql 解决方案都是不同的。我想知道是否有人对特定的 no-sql 数据库有任何特定知识，可以引用为什么该特定数据库对解决方案有好处。

Answer 1

这似乎有点超出 StackExchange 问题的范围。然而.....

NoSQL 数据库通常用于解决关系模型的特定问题。解决的最常见问题是可扩展性。然而，因为它们都是为了解决某些应用程序在关系模型中遇到的某些问题的不同方面而设计的，所以对于它们作为一个整体，您真的无法说些什么。也许您需要处理数 TB 的数据？或者您可能需要处理一个非常动态的数据模式，而 EAV 类型的模式只会降低性能？也许您想要一个更关心可用性而不是一致性的数据存储（请参阅CAP 定理）？每个人擅长的东西可能与另一个人擅长的东西大不相同，而 RDBMS 是一个更通用的数据库。

我从我信任的人那里听到的回答是，如果您还不知道为什么需要为 NoSQL 放弃传统的 RDBMS，那么您几乎肯定应该坚持使用 RDBMS。人们花了 30 年时间才开始认真考虑 RDBMS 之外的数据存储模型，这是有原因的。如果您的查询需要 MySQL/MariaDB 中没有的功能，您可能希望考虑另一个具有更强大功能集的 RDBMS。那可能是 PostgreSQL、Oracle 或 MS SQL Server。

您在这里提出的模式已经非常适合关系模型。对于多对多关系，您可能需要一些联结表，但我认为您不一定会看到其中的许多。如果您正确调整数据库大小，正确索引您的表，并分析您的常见查询——您也必须使用 NoSQL 做的事情——我认为您不会有大问题。您甚至可以避开最常见查询的视图。

Answer 2

基本上你在这里有很多选择。

1. 关系型
2. 非关系
3. 混合（基本上是关系数据和一些非关系形式的扩展数据，如 XML 等）。

您最初的讨论表明您的数据本质上是表格形式，因此关系模型自然适合您的数据。

要记住的第二点是，关系模型在数学上定义得很好，这有助于您稍后将数据重新用于分析，而您现在可能没有考虑过。

然而，非关系模型的承诺之一是更好的 API。我建议可以通过存储过程接口来封装关系模型，该接口专注于可发现性，可以与您的应用程序松散耦合。你没有提到 PostgreSQL，但我在我的博客上写了一些关于如何做到这一点的方法。首先阅读的是http://ledgersmbdev.blogspot.com/2011/10/introduction-to-soda.html