1

私は2つのテーブルを持っています：

  • auth認証情報が含まれています
  • usersユーザープロファイル情報が含まれています

auth列がありusernameます。これは、ログインクレデンシャルとしても、ユーザーのプロファイルURLの一部としても機能します（例example.com/profiles/username）。

ユーザーのリストを取得する場合、ユーザー名はプロファイルへのURLを作成するために必要です。現在、私はテーブルをクエリし、usersテーブルを結合しauthてこの情報を取得しています。usernameただし、がの列でもある場合は、その結合を回避しusersて、2つの異なるテーブルに2つの同一の列を作成できます。

列が重複するという考えは好きではありませんが、結合を1つ減らすことは常に良いことです。これは、データベーススキーマ（または他の何か）を作り直す必要があることを示していますか、それとも冗長性が許容できる場合の例ですか？

4

3 に答える 3

7

スキーマの正規化（つまり、冗長性の削除）は、時間の効率に対処するようには設計されていませんが、a）空間の効率（データの重複コピーを排除することによる）およびb）一貫性（複数の場所に同じ情報を保存しないことによる）ではありません。彼らが同意しないリスクを冒してください）。その観点から、結合を使用する必要があることは、これらの他の利点のコストです。

于 2012-12-21T23:35:28.287 に答える
1

アプリケーションの全体像がなければ、良い答えを出すことは非常に困難です。個人的には、ユーザー名などの情報を複製するのは良い考えではないと思います。

このような設計上の決定を行うときは、システムのメンテナンス/将来の開発などを考慮する必要があります。いくつかのポイント：

  • ユーザー名は将来ユーザーによって変更される予定ですか？列が重複していると、単純な更新が複数のテーブルを更新するための非常に困難な作業になることがあります（情報を一度複製すると、他のチームがその例に従って何度も実行できます）。
  • システムが異なるチームによって開発または保守されている場合（システムを十分に理解している必要はありません）、一部のテーブルで重複を見逃し、データの不整合を引き起こす可能性があります。

それがお役に立てば幸いです。

于 2012-12-21T23:52:23.853 に答える
1

「参加が1つ少ないことは常に良いことです」。私はそれを問題にします。データベースは、テーブルを結合するために設計されています。追加の結合には、通常、次のような作業が必要です。

  1. 2番目のテーブルのインデックスでキーを含むページを検索します。インデックスはメモリ内にあるはずなので、非常に高速です。
  2. 値を使用して2番目のテーブルを取得します。
  3. ページ上のデータを処理しています。

これは大変な作業のように聞こえるかもしれませんが、実際にはせいぜい数ミリ秒の労力です。

2番目のテーブルがメモリに収まる場合、またはインデックスにユーザー名フィールドを含めて2回目の読み取りが不要な場合、これはすべて非常に高速に行われます。確かに、平凡なハードウェアから1秒あたり5,000トランザクションを取得しようとしている場合は、気になるかもしれません。ほとんどの場合、余分な数ミリ秒（せいぜい！）は高価ではありません。

この余分な仕事はあなたに何を買いますか？変更されている場合は、ユーザー名が最新のユーザー名であることを確認します。

アプリケーションには他の要件がある場合があります。パフォーマンスが重要になる場合があります。その場合、データの非正規化が役立つ場合があります（ただし、複合インデックスはパフォーマンスの点でかなり近い可能性があります）。メモリが制限された環境にいる可能性があります。その場合、1ページの読み取りですべてのユーザーデータをロードすることが重要になる場合があります。ユーザー名は決して変更されない可能性があります。その場合、ユーザー名をテーブルの主キーにすることを検討してください。つまり、非正規化が深刻なオプションになる状況があります。

間違いなく他のケースもあります。たとえば、ほぼすべての分析は、非正規化されたデータ構造から機能します。

于 2012-12-22T00:31:37.057 に答える