アプリケーションにNoSQL（MongoDB）またはSQL（postgresql）データベースを使用する必要がありますか？
Slido に似たライブオーディエンスインタラクションWebアプリケーションを練習/楽しいプロジェクトとして構築することを計画しています。
ユーザーグループ：管理者と匿名ユーザー
管理者：
ログインする
イベントを作成（イベント期間と一意のイベントコード/名前を定義）
ユーザーの質問を編集/削除する
ユーザーの質問を強調表示する（イベントごとに最大3つの質問）
匿名ユーザー：
イベントコード/名前を入力してイベントに参加する
イベント期間が現在の時刻と一致する場合、イベントに参加する
イベントページで質問する
他のユーザーからの質問の最新情報を確認する
時間/最も賛成票で質問を並べ替える
他の質問に賛成/反対票を投じることができます
このようなアプリケーションの場合、NoSQLまたはSQL dbの方が適していますか？
アドバイスありがとうございます。
更新！
以下は、私が思いついたリレーショナルおよび非リレーショナルスキームのデータモデルです。それについてのフィードバックが欲しいです：
リレーショナルスキーム：
管理者
id（シリアル主キー）
ログインする
パスワード
名前
イベント
id（シリアル主キー）
イベント名
event_code
始まる時間
終了時間
admin_id（外部キー参照admin.id）
ユーザー
id（シリアル主キー）
名前
eメール
ご質問
id（シリアル主キー）
event_id（外部キー参照events.id）
post_time
user_id（外部キー参照users.id）
コンテンツ
Question_upvote
id（シリアル主キー）
question_id（外部キー参照questions.id）
user_id（外部キー参照users.id）
Question_highlight（管理者が使用）
id（シリアル主キー）
question_id（外部キー参照questions.id）
非リレーショナルスキーム：
管理者ドキュメント
{
uid:
login:
password:
name:
events: [event1, event2 ...]
}
イベント文書
{
uid:
eventName:
eventCode:
startTime:
endTime:
adminId:
users: [user1, user2, ...]
highlightedQuestions: [question1, question2, ...]
}
質問文書
{
uid:
eventId:
userId:
content:
userLikes: [user1, user2, ...]
postTime:
}
ユーザー文書
{
uid:
name:
email:
}
プロジェクトの最初にDBMSテクノロジーを選択する際に考慮すべき多くの質問があります。私が頭に浮かぶ最初の2つは次のとおりです。
- データのモデル化はどのくらい簡単ですか？
- 今後、データにはどのようにアクセスしますか？
残念ながら、ここで提供する情報はあなたに助言するには不十分です。それにもかかわらず、あなたを助けることができるいくつかの考えがあります。
1.データのモデル化はどのくらい簡単ですか？
あなたのユースケースから、モデルの次のエンティティを想像します：Users、Events、Questions（イベントの場合）、Votes（質問の場合） ）、そしておそらくAnswers（これは明示的ではありませんが、ユースケースリストの質問には誰も答えません）。
データはかなり構造化されており、十分に確立された関係にあるため、これはリレーショナルスキームでモデル化するのが非常に簡単です。
しかし、MongoDBなどのNo-SQLドキュメントデータベースで非常に簡単にモデル化することもできます。たとえば、Userは1種類のドキュメントであり、Eventsは独立した種類のドキュメントです。 Questionsは、Eventsに埋め込まれたサブドキュメントのリストになります。
ヒント1：DBMSテクノロジーを選択する前に、ドメイン。これは、必要なデータ構造を理解し、実装の選択肢を特定するのに役立ちます
2.データへのアクセス方法は？
リレーショナルモデルでは、関係を簡単に参照できます。任意のエンティティを選択し、必要なものが得られるまで関係を追跡します。たとえば、ユーザーを選択し、関連する質問を見つけ、関連するイベントを見つけます。または、イベントから始めて、関連する質問とユーザーを見つけます。完全なナビゲーションの柔軟性。
ドキュメントデータベースでは、アクセスの主要なパスをさらに分析し、更新コストと取得パフォーマンスのトレードオフを検討して、設計を選択する必要があります。たとえば、MongoDBの場合、通常は より便利な埋め込みモデルを使用するか、よりパフォーマンスの高い正規化モデルを使用するほうがよいか になります。
ヒント2：モデルで、必要な方法を特定します特定したさまざまなユースケースのデータにアクセスします。次に、リレーショナルおよびドキュメントベースのアプローチでそれをどのように行うかを想像してください。
ヒント3：ここで、複数のユーザーが質問または更新したいと考えているとします質問。同時実行が原因で更新の競合が発生する可能性はありますか？検討しているさまざまなDBMSスキームでどのように対処できますか？
最終的な考え
経験則として、リレーショナルモデルは、データがかなり構造化されており、安定している限り、非常に柔軟です。個人的には、私はあなたのケースではこのアプローチを最初の選択肢として選びますが、それを正当化する有効な議論はありません。
データがあまり構造化されていない場合、構造が頻繁に進化する場合、または特殊なデータ構造の場合は、「SQLなし」エンジン（SQLはクエリ言語にすぎないため、実際には非リレーショナルDBMS）が適しています。
これに関して、MongoDBのようなドキュメントストアがより一般的に使用されているように見える場合でも、異なる種類の No-SQL があることに注意してください。グラフデータベース、タプルストア、列ストアなどもあります。ご覧のとおり、各種類は、データまたはデータへのアクセス方法に関する特定のニーズに対応しています。ドメインに対するそのような必要性を認識しますか？この質問に答えると、探している応答が得られます。