私には独特の状況があります。私のサイトのユーザーは、他のユーザーがレビューできるように記事を送信できますが、記事をレビューできる人を年齢や国によって制限できます。私の問題は、250 のレコード (記事にリンクしている国ごとに 1 つ) を持つ代わりに、250 の国すべて (または他のユーザーに表示したい国) を JSON 形式で、データベース。この方法では、記事ごとに 1 つのレコードしか必要ありません。パフォーマンスがひどく損なわれるかどうかわかりませんか? このサイトは 100 万から 200 万のユーザーを処理し、レビューのために送信される記事の数もかなり多くなります。実行される唯一の「処理」は、各ユーザーの
皆さんはどう思いますか？記事ごとに 250 レコードというのは、考えすぎですか?
ルックアップ テーブルにデータを格納することはまったく問題ないと思います。これにより、将来何かが変更された場合の自由度が大幅に高まります。また、テーブルのインデックスを適切に作成している限り、パフォーマンスがそれほど低下することはありません。
Mysql は、何十億ものレコードであるデータを簡単に処理します。はい、データの整合性を確保する必要があります。ただし、すべてのレコードに格納されているオブジェクトを変更するよりも、ルックアップ テーブルに列を追加する方がはるかに簡単に思えます。
繰り返す必要のない情報を繰り返さないなど、データを適切に保持していることを確認してください。国を 1 つのテーブルに保持し、それを参照するルックアップ テーブルに単純な ID を保持します。
要するに、リレーショナル データベースの列に Json データを格納することは、その列に基づいてデータをクエリする予定がない場合は問題ないと言えます。
その列に基づいてデータを検索する必要がある場合、データを除外する前にjsonを解析する必要があるため、パフォーマンスが大幅に低下するため、これはできません。
私の仕事では小規模でこの問題に遭遇しましたが、プロパティの json をデータベースに保存することで、検索されていないプロパティのデータベースの複雑さが増すことはありませんでした。
そのデータの代わりに別のテーブルを使用し、それに一致する一意の列を作成します。
「国」テーブルと「記事」テーブルがあります。一致するインデックスのみで構成される 3 番目の「国の記事」を作成します。結局、Mysql はリレーショナルです。性能が気になるならベンチマーク。
国ごとに個別のテーブルを作成し、そのIDを記事テーブルに保存することができます。
すべての国、アジア、ヨーロッパ、北アメリカ、南アメリカなどのオプションを国のテーブルに保存できます。
1 つのオプションとして、MySQLビットまたはバイナリタイプを使用して、ビットフィールドを使用して国を表すことが考えられます。これにより、各国の情報を 1 ビットに格納することができ、レコードごとに追加で 32 バイトしか必要としません (8 ビット/バイト * 32 バイト = 256 ビット)。
確かではありませんが、ビット単位の操作を使用してクエリを実行することも可能であり、非常に高速になる可能性があります。
JSON は、DBMS が保存したい国の有効性をチェックするのを防ぎます。これは基本的に不透明なテキストであるため、DBMS は参照整合性 (外部キー) を適用できません。
また、国を照会する必要がない場合でも (これは非常に大きな問題です)、特定の国を確認する前に、少なくとも JSON を解析する必要があります。
JSON は階層データに適していますが、これは単純なセット (国がセットの要素であるかどうかにかかわらず) であり、別のジャンクション テーブル ARTICLE_COUNTRY でうまく表現でき、効率的に維持および検索できます。 :
このジャンクション テーブルは、記事にアクセスできる国にのみリンクします。ほとんどの国からほとんどの記事にアクセスできる場合は、ジャンクション テーブルの意味を逆にして、「禁止された」国のみを格納することもできます。これにより、全体の行数を減らすことができます。