私の場合、MongoDBは正しい選択ですか？[閉まっている]
閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 6年前休業。 3つの主要な部分で構成されるWebアプリで構成される、Railsで最初の実際のプロジェクトを構築します。 データベースを使用しない静的部分 各ユーザーの行は同じフィールドを持つため、データベースを必要とし、MySQLを使用できるユーザー登録部分 ユーザーがコレクション内のアイテムを作成、整理、編集し、他のユーザーと共有できる「アプリ」 いくつかのアイテムタイプがあり、それぞれに異なるオプションがあります。たとえば、次のオプションを持つ「ビデオ」アイテムがあるとします。 id ユーザーID collection_id 題名 プラットフォーム（埋め込まれている場合） URL（埋め込まれている場合） ファイル名（アプリでホストされている場合） ファイルサイズ（アプリでホストされているID） 「マップ」アイテム： id ユーザーID collection_id 題名 プラットフォーム（Googleマップ、Bingマップ...） ロケーション url 地図のサイズ ユーザーがMySQLをアイテムに使用している間、各アイテムが別のアイテムとは異なるオプションを必要とする可能性があるため、MongoDBの柔軟性が役立つ場合があります。 これまで私は常にPHPとMySQLを使用してきました（常に小規模なプロジェクトでは共有ホスティングを使用しています）。スケーラビリティは私にとってまったく新しい言葉です。 学ぶ時間はありますが、1か月くらいで具体的なことができるようになりたいです。 私はMongoDBとNoSQLとRDMSとMySQLについてたくさん読んだので、それを試した後、MongoDBがどのように機能するかが好きだと言っておく必要があります。 私の状況では何をしますか？どうして？ スケーラビリティについて、MongoDBに問題がある可能性はありますか？はいの場合（DBサイズに関して）、これらの問題によりアプリが大幅に遅くなる可能性がありますか？ 編集：アプリの仕組み 多くの人がこれを私がアプリをどのように機能させたいかを尋ねたので： ユーザーがサインアップ 彼はログインしています 彼は無限のアイテムを作成できる彼の最初のコレクションisideを作成します アイテムにはさまざまなタイプがあり、タイプごとに異なるデータをデータベースに保存する必要があり、アイテムのタイプを追加または変更できます ユーザーはその中に他のコレクションやアイテムを作成できます。 そのため、コレクションとその内部のアイテムのCRUDがあり、各コレクション/アイテムは特定のユーザーに参照されます MySQLの主な問題は、柔軟なスキーマがないことです。これを解決する方法があります（回避策？）？ NoSQLについて考えるときの唯一の疑問は、結合に関するものです。たとえば、特定のコレクションがあり、コレクション内のID = user_idフィールドを持つユーザーに関連するデータを取得したい場合 編集：MySQLを使い続けるためのアイデア 「items」テーブルに、オプション設定を含むフィールドを作成します。各設定は|で区切られます。または別のシンボル。 次に、各アイテムのオプション設定の構造をどこかに保存します。たとえば、「ノート」アイテムタイプには、MySQLからデータを取得するときに、2つのオプション設定「color」と「strange_setting」が必要です。オプション設定のフィールドを配列の最初の項目が「色」用であることを認識する配列など。 どう思いますか？その解決策に問題がありますか？他にアイデアはありますか？