データベースの設計：異なるテーブルに分割するか、それらをグループ化しますか？
私はデータベース設計にかなり慣れていないので、自分のフォーラムベースのアプリケーションを構築しようとしています。アプリは次のようにネストされたカテゴリを持ちます
countries > systems > levels > subjects
すべての主題カテゴリで、ユーザーは同じタイプのデータにアクセスします。ユーザーはスレッドを投稿して回答することができ、それに応じて各回答に返信できます（stackoverflowやquoraのしくみと同じように）。ユーザーはトピックを検索でき、80％の時間、自分の主題に関連するトピックのみを検索します。それは彼らが他の国や他のシステムや他のレベルにアクセスする可能性が非常に低いことを意味しますが、私はその機能も維持したいと思います。
標準のデータベース設計に従って国、システム、レベル、サブジェクトを別々のテーブルに分け、それらの主キーを特定のフォーラムスレッドの外部キーとして使用するかどうかを考えています。しかし、ユーザーから特定のトピックを検索するために頻繁に使用されるため、私の懸念はパフォーマンスの問題です。すべての検索がJOIN機能をトリガーする必要があると想像してください。
しかし、私はいくつかの調査を行ったところ、受け入れられた答えがここにあることがわかりました https://stackoverflow.com/questions/8479252/database-design-3-types-of-users-separate-or-one-table フォーラムのスレッドに同じ属性がある場合は、それらを1つのテーブルにグループ化することをお勧めします。ただし、検索機能に関してもパフォーマンスの問題があります。すべての検索はデータベースを行ごとにトラバースする必要があり、国、システム、レベル、およびサブジェクト属性の点で無関係な行があります。スレッドテーブルの行が数十万に増えたとします。
行くための最良の方法は何でしょうか？それともNoSQLを検討すべきですか？
経験則として、パフォーマンスの最適化をあまり考慮せずにデータベーススキーマを設計し（特に初めての場合）、パフォーマンス上の理由から必要に応じて変更することをお勧めします。 Deliothが指摘しているように、実際に機能するまで、実際のボトルネックはわかりません。
一般に、パフォーマンスを最適化するためにコアテーブル構造を変更する必要はありません。最新のリレーショナルデータベースは、正しいインデックスを使用して、数百万行のテーブルでも非常に迅速に結合とクエリを実行できます。前もって何かに焦点を当てる場合は、これらの一般的なクエリと結合で必要になるインデックスに焦点を当てます。
一般に、実際の要件に一致するようにデータモデルを設計し、時期尚早な最適化をコミットしないでください。数十万行は、最新のデータベースエンジンにとって問題ではありません。
パーティションキー が何であるかを考えてください。パーティショニングを行うと、データを論理的に1つのセットに保ちながら、データベースがより小さなデータセットで動作するように最適化できます。この概念は [〜＃〜] sql [〜＃〜] および [〜＃〜] nosql [〜＃〜] に存在します。
また、データベースの選択についても検討してください。 ACIDデータベースは、多くの約束を守るために努力しています。それらすべてが必要ですか、または「最終的に一貫性のある」アプローチで対応できますか（リソース要件を下げ、スケーラビリティを支援します）。
価値のある読み物： Sharding Pinterest：MySQLフリートのスケーリング方法