イベントデータベースのリレーショナルデータベースと非リレーショナルデータベース
イベントデータベースの作成には、SQLソリューションと非SQLソリューションのどちらが優れているかを調べています。チケットマスターと同様のチケットシステムを作成しています。どちらのデータベースタイプのストレージも簡単な部分であることは知っています。決定的な要素は、次のクエリのパフォーマンスです。
- 特定の日付範囲内の場所でイベントを選択します。
- 特定の場所（市、町など）のすべてのイベントを選択し、日付順に並べ替えます。
- 特定の日付範囲内、特定の場所内のキーワードでイベントを検索します。
イベントには基本的にID、NAME、LOCATION、VENUE、開始日、終了日があります
リレーショナルスキーマでは、EVENTSテーブル、複数の日付でイベントが発生する可能性があるため別々に日付を格納するDATESテーブル、およびイベントが繰り返されるVENUESテーブルがあり、そこからイベントの場所（国、都市など）を指定できます。相互参照。
私はno-SQLデータベースの経験がないので、no-SQLに投票する場合は、「スキーマ」がどのように編成されているか、およびどの特定のDBがどのように見えるかを提案してください。
この質問が十分具体的であることを願っています。クエリのパフォーマンスが決定的な要素です。
さらに検討を重ねた結果、日付範囲のクエリを高速化できる日付/時刻関数の可用性がより適切に抽出されていることに気付きました。 MySQLとPostgreSQLにそのような機能があることは知っています。 PostgreSQLは構文の点でこの時点で少し良くなっています。これに関してNoSQLソリューションが何を提供する必要があるのかわかりません。
このシステムは確かにリレーショナルデータベースで快適にモデル化できることを知っています。また、それぞれの非SQLソリューションが異なることも認識しています。特定のSQL以外のDBについて特定の知識を持っている人なら誰でも、その特定のDBがソリューションに適している理由を挙げられるだろうかと思っていました。
これはStackExchangeの質問の範囲から少し外れているようです。しかしながら.....
NoSQLデータベースは通常、リレーショナルモデルの特定の問題を解決するために構築されます。対処される最も一般的な問題はスケーラビリティです。ただし、これらはすべて、リレーショナルモデルを使用した一部のアプリケーションの特定の問題のさまざまな側面に対処するように設計されているため、全体としてそれらについてすべて言えることはありません。おそらく、テラバイトのデータを処理する必要がありますか？または、全体にわたって非常に動的なデータスキーマを処理する必要があり、EAVタイプのスキーマはパフォーマンスを低下させるだけでしょうか？たぶん、一貫性よりも可用性を重視するデータストアが必要ですか（ CAP定理 を参照）？ RDBMSははるかに一般化されたデータベースですが、それぞれが他の得意なものとは大きく異なる可能性があるものに優れています。
私がこのトピックについて信頼している人々から聞いた答えは、NoSQLの従来のRDBMSを放棄する必要がある理由がまだわからない場合は、ほぼ確実にRDBMSに固執する必要があるということです。 RDBMSを超えてデータストアモデルを真剣に検討し始めるまでに30年かかった理由があります。 MySQL/MariaDBで利用できない機能がクエリで必要な場合は、より堅牢な機能セットを持つ別のRDBMSを検討することをお勧めします。 PostgreSQL、Oracle、MS SQL Serverなどが考えられます。
ここで提案するスキーマは、すでにリレーショナルモデルにかなり適しています。多対多の関係にはいくつかのジャンクションテーブルが必要になる場合がありますが、必ずしもそれらの多くが表示されるとは限りません。 DBのサイズを適切に設定し、テーブルのインデックスを適切に作成し、一般的なクエリを分析すると（NoSQLで行う必要があることも）、大きな問題が発生することはないと思います。最も一般的なクエリのビューを回避することもできます。
基本的にはここにたくさんのオプションがあります。
- 関連した
- 非リレーショナル
- ハイブリッド（基本的に、XMLなどの非リレーショナル形式の拡張データを含むリレーショナルデータ）。
最初の議論では、データは本質的に表形式であるため、リレーショナルモデルが自然にデータに適合することが示唆されています。
留意すべき2番目のポイントは、リレーショナルモデルが数学的に適切に定義されていることです。これにより、後で考えていない分析のために後でデータを再利用できます。
ただし、非リレーショナルモデルの約束の1つは、より優れたAPIです。リレーショナルモデルは、アプリケーションと疎結合できる発見可能性に焦点を当てたストアドプロシージャインターフェイスを通じてカプセル化できることをお勧めします。あなたはPostgreSQLについて言及していませんが、ブログでこれを行う方法についてかなり説明しました。最初に読む http://ledgersmbdev.blogspot.com/2011/10/introduction-to-soda.html
「リレーショナルかどうか」という質問は、この2つは何らかの形で比較可能であるという誤った仮定に基づいています。ではない。あなたが尋ねている質問は、より建設的に表現されているかもしれませんトランザクションをサポートし、証明可能な正しい結果を提供するものである、数学と論理に基づいたDBMSを使用すべきか、それとも自分で構築すべきか？
指標は次のとおりです。1秒あたり数百万のトランザクションを処理していない場合、または1日あたりテラバイトのデータを追加していない場合は、おそらくNo-SQLの領域に属していません。その規模で問題が発生した場合、雇用主にとっては、特大のニーズに対処するために非常に具体的な何かをまとめるのにお金を払うことは価値があります。それがなければ、ハードウェアが$ 50,000あれば、名前を付けたいSQL DBMSを非常に迅速に実行でき、正確な結果と信頼できる操作の保証が向上するため、時間と費用の節約になります。