事件數據庫的關係數據庫與非關係數據庫
我正在嘗試找出 SQL 或非 SQL 解決方案是否更適合創建事件數據庫。我正在創建一個票務系統，類似於票務大師。我知道對於任何一種數據庫類型的儲存都是簡單的部分。決定因素是以下查詢的性能：
- 在特定日期範圍內按位置選擇事件。
- 選擇給定位置（城市、城鎮等）的所有事件，按日期排序。
- 在特定日期範圍內、特定位置按關鍵字搜尋事件。
事件基本上有 ID、NAME、LOCATION、VENUE、START DATE、END DATE
在關係模式中，我將有一個 EVENTS 表，一個用於單獨儲存日期的 DATES 表，因為事件可以在多個日期發生並且它們是可重複的，以及一個 VENUES 表，事件位置（國家、城市等）可以從交叉引用。
我沒有使用非 SQL 數據庫的經驗，因此如果您投票支持非 SQL，請建議您如何看待“架構”的組織方式以及特定的數據庫。
我希望這個問題足夠具體。查詢性能是決定因素。
經過進一步考慮，我意識到這個問題更恰當地提煉為可以促進快速日期範圍查詢的日期/時間函式的可用性。我知道 MySQL 和 PostgreSQL 有這樣的功能。就語法而言，PostgreSQL 在這一點上甚至看起來更好一些。我不知道 NoSQL 解決方案必須提供什麼。
我知道系統當然可以在關係數據庫中輕鬆建模。我也知道每個 no-sql 解決方案都是不同的。我想知道是否有人對特定的 no-sql 數據庫有任何具體知識，可以引用為什麼該特定數據庫對解決方案有好處。
這似乎有點超出 StackExchange 問題的範圍。然而…..
NoSQL 數據庫通常是為了解決關係模型的特定問題而建構的。解決的最常見問題是可擴展性。但是，因為它們都是為了解決某些應用程序在關係模型中遇到的某些問題的不同方面而設計的，所以對於它們作為一個整體，你真的沒有什麼可以說的。也許您需要處理數 TB 的數據？或者您可能需要處理一個非常動態的數據模式，而 EAV 類型的模式只會降低性能？也許您想要一個更關心可用性而不是一致性的數據儲存（請參閱CAP 定理）？每個人擅長的事情可能與另一個人擅長的事情大不相同，而 RDBMS 是一個更通用的數據庫。
我從我信任的人那裡聽到的關於這個主題的回答是，如果您還不知道為什麼需要放棄傳統的 RDBMS 來使用 NoSQL，那麼您幾乎可以肯定應該堅持使用 RDBMS。人們花了 30 年才開始認真考慮 RDBMS 之外的數據儲存模型，這是有原因的。如果您的查詢需要 MySQL/MariaDB 中不可用的功能，您可能希望考慮另一個具有更強大功能集的 RDBMS。那可能是 PostgreSQL、Oracle 或 MS SQL Server。
您在這裡提出的模式已經非常適合關係模型。您可能需要一些用於多對多關係的聯結表，但我認為您不一定會看到其中的許多。如果您正確調整數據庫大小、正確索引表並分析常見查詢——您也必須使用 NoSQL 做這些事情——我認為您不會遇到大問題。您甚至可以擺脫最常見查詢的視圖。