特定のテーブルに100,000のレコードがあるアプリを再設計している最中です（現在は25万で、増え続けています）。
この表には、Webサイトとドメインの情報が含まれています。
速度とリソースのために、いずれかのエンティティに必要なすべてのデータを元のテーブルに含めるか、共有されていない情報を格納するために2つのルックアップテーブルを使用する必要があります。たとえば、すべてのドメイン固有の情報を格納する1つのルックアップテーブルと1つのルックアップテーブルすべてのサイト固有の情報を保存しますか？
ありがとう
理想的には、それらを2つの異なるテーブルに分割する必要があります。これは、単一のドメインが複数のサイトに対応し、ドメインとサイトの両方のメタデータが単一のテーブルに格納される設計を採用する場合、その場合はサイトメタデータのすべてのレコードにドメイン用に保存された冗長な情報。代わりに、ドメインテーブルにドメインごとに1つのレコードがあり、レコードのフィールドの1つとしてサイトのリストがあり、サイトテーブルのドメイン名列にサイトが指定されたドメインを把握する2つの別々のテーブルがある場合、整理されたストレージを確保し、データの冗長性をなくします。これが従来のRDBMSシステムの主要な原則であり、それが複数のテーブルの概念を持っている理由です。
また、データが継続的に増加していると述べたように、データベースを実際にスケーリングしたい場合は、NOSQLデータストアの使用を検討することもできます。Apache HBaseは、関連情報をグループ化するというこの概念を備えた優れたソリューションである可能性があります。
編集：
質問の明確化：
Just to be clear, domain and sites are not linked. They're just different entities like a domain with no traffic or revenue would be classed as a domain and have domain related data stored for it like number of hyphens or registrar while a domain with a Wordpress install for example and exisitng traffic would be classed as a site - not a domain - and have site specific information stored. Would this change your answer?
それらが相互に関連していない場合、分散RDBMSシステムを使用しない限り、データを複数のテーブルに分割することは何の役にも立たないと思います。単一ノードでホストされるDBの場合、行はとにかくサイト/ドメインIDによってインデックス付けされ、単一のテーブル内の多数の行によってパフォーマンスが低下することはありませんが、膨大なサイズのデータを調べている場合はクラスタ内の複数のノードに分割し、それらに独立したテーブルを用意すると、各テーブルが個々のノードでホストされ、DBを水平方向に拡張できるようになります。この場合、それが唯一のメリットです。
アプリケーションのパフォーマンスは、アプリケーションが使用するクエリの種類に大きく依存します。すべてのデータを1つのテーブルに格納しても、必ずしもパフォーマンスが低下するわけではありませんが、パフォーマンスが向上する可能性があります。もちろん、example.comがXY氏によって数千回所有されているという情報がテーブルに保持されている場合は、ディスク領域を浪費しています。
データベースを正規化する（データを分割する）ことは役立つ場合がありますが、それに答えるには、データをどのように処理するかを知っている必要があります。