データベースの冗長フィールドを合理的に使用する方法

privot は、多対多の関係の中間テーブルです。 PT5 フレームワークは自動的に privot を起動します。

privotは必要ないので非表示にする必要があります。また、privotはモデル自体には含まれておらず、中間データです。

冗長フィールドに加えて、写真を記録するためのテーブルと製品を記録するための別のテーブルがあります。

商品画像のURLを画像内に載せることができます

同時に、商品に画像IDと画像URLを入れてください

これら 2 つのフィールドは繰り返され、データの冗長性が生じます。データベースは冗長な情報を回避するように設計されているのに、なぜ冗長性を使用するのでしょうか。

これは主にクエリのパフォーマンスを考慮するためです。

ここでデータの冗長化を行ったので、画像テーブルへのクエリの数を減らし、クエリを高速化できます。

ただし、データの冗長性によりデータの整合性と一貫性を維持することが困難になるため、データの冗長性を乱用することは推奨されません。同じ情報を記録する場所が 2 つありますが、データを書き込むときは 2 つの場所に書き込む必要があります。最大の問題は削除と更新です。更新時に、1 か所の IMG が変更された場合は、両方を変更する必要があります。そうしないと、データの不整合が発生します。ただし、データの冗長性は依然としてかなり使用されています。

WEB 開発では、いくつかの必要なデータベース最適化技術を習得することに加えて、適切なタイミングで冗長フィールドを使用することで、半分の労力で 2 倍の結果を達成することもできます。たとえば、次の例では、このように設計されたテーブルがいくつかあります。

• ユーザーテーブル [user]: id、userName
• プロジェクト テーブル [プロジェクト]: id、projectName、user_id
• バージョン テーブル [バージョン]: id、versionName、project_id
• カテゴリ テーブル [category]: id、categoryName、version_id
• コンテンツテーブル [コンテンツ]: id、テキスト、category_id

それはそれくらいです。冗長なフィールドがなく、見栄えが良いです。また、データベース設計の 3 つの主要なパラダイムにも準拠しています。

まず質問をしましょう。これを質問 X と呼びましょう。

質問 X: 特定のバージョンのコンテンツ リストをクエリする場合、SQL は次のように記述する必要があります。

コンテンツ c、カテゴリ t から c.* を選択します。c.category_id=t.id かつ t.version_id=?

問題はなさそうです。このクエリを最適化するにはどうすればよいでしょうか?この質問については最後に議論します。そのような問題がある場合は、上記のテーブル設計に戻りましょう。たとえば、コンテンツ A がユーザー U に属しているかどうかを確認したいのですが、どうすればよいでしょうか?

• コンテンツAが属するカテゴリBを検索する
• カテゴリ B のクエリ バージョン C
• バージョン C が属するプロジェクト D を照会する
• アイテムDがユーザーUに属しているかどうかを照会し、コンテンツAがユーザーUに属しているかどうかを判断します。

これは非常に悪い行為ですよね？この時点で、このテーブル設計の弱点に気付いたはずです。それで私たちは何をすべきでしょうか?

冗長なフィールドです!はい、テーブルに冗長フィールドを追加する必要があります。上記の各テーブル (ユーザー テーブルを除く) に user_id フィールドを追加するとどうなるでしょうか?

まず、各テーブルの user_id フィールドの値は変更されないことが保証されます。したがって、このフィールドの値は一度設定したら変更する必要はありません。

次に、上記の質問に戻り、コンテンツ A がユーザー U に属しているかどうかを照会します。現在のアプローチは次のとおりです。

コンテンツAのuser_idがユーザーUのIDであるかどうかを確認する

たった一歩！とても単純で粗雑ですよね？かなり爽やかですよね？

冗長フィールド user_id を追加するだけで、コーディング量が大幅に削減され、データベース クエリの効率が N 倍向上します。また、このフィールドは一度だけメンテナンスする必要があります。

冗長フィールドの威力がわかったので、質問 X に戻りましょう。そのビジネスロジックを最適化するにはどうすればよいでしょうか?

正しいアプローチは、コンテンツ テーブルに version_id フィールドを追加することです。このフィールドは us​​er_id フィールドに類似しており、一度だけメンテナンスすれば済むことは確かです。

すると、質問 X の SQL は次のように変更されます。

c.version_id=? のコンテンツ c から c.* を選択します。

とてもシンプルなSQLです!

上記は、適切なデータベース冗長性が場合によっては良い選択であることを示しています。

要約する

以上がこの記事の全内容です。この記事の内容が皆様の勉強や仕事に何らかの参考学習価値をもたらすことを願います。123WORDPRESS.COM をご愛顧いただき、誠にありがとうございます。これについてもっと知りたい場合は、次のリンクをご覧ください。