1

オンライン小売店のERD図を設計しています。関連するすべての詳細が格納されている顧客テーブルがあります。また、以下を含む顧客ログイン詳細テーブルもあります。メールとパスワードのフィールド。私が利用できる唯一の関係は1対1であり、電子メールは2つの間のリンクです。

私の質問は、このテーブルを顧客のテーブルに吸収したほうがよいかどうかです。またはそれを分離しておくことに何か利点はありますか？

データベースは私の強みではないので、助けてくれる人に感謝します

4

2 に答える 2

3

はい、そのような1対1の場合、すべての詳細を1つのテーブルにまとめたいと思います。

いくつかの例外は次のとおりです。

  • パフォーマンス。数十万人のユーザーがいる場合は、メインテーブルをできるだけ「薄く」する必要があります。これは、単一の詳細を1対1のテーブルに移動することを意味する場合があります。

  • データベースのセキュリティ。他のユーザーの詳細とは別のフィールドにパスワードを設定すると、ユーザーの詳細テーブルへのアクセスを遅くしたり妨げたりすることなく、そのテーブルを保護するためにより多くの作業を行うことができます。ユーザーの詳細には個人情報が含まれますが、実際に何かを行うための詐欺師のアクセスを許可するパスワードほど重要なものはほとんどありません（偽のログインでより多くの個人情報を簡単に見つけることを含む）。

  • ERDのセキュリティ。質問のタイトルにERDが含まれているため、テーブル名と列名をパスワードで実際に省略できるERDを表示すると、それらが別のテーブルにある場合にはるかに簡単になります。これは、ERDを共有し、デモを行うときに必要になる場合があります。等

  • 複数のログインの要件。Stack Exchangeのようなサイトでは、複数のアカウントを1つのマスター「ログイン」に関連付けることができます。これらのシナリオでは、ユーザー名とパスワードを別々に設定すると、実際には1対多の関係になります。したがって、1対1の関係が決して変わらないと確信している場合、および/または実際に作成される前に機能を予期していないアジャイルプロセスに取り組んでいる場合は、個別に必要ではありません。

于 2012-11-24T16:27:27.203 に答える
0

すべての列が顧客に直接関連していて、冗長性（繰り返し行）を与えない場合は、それらを同じテーブルに保持します。たとえば、次のフィールド：名前、家族、電子メール、およびパスワードはすべて、ユーザーエンティティと密接に関連しているという理由だけで、ユーザーである同じテーブル（エンティティ）に存在する必要があります。

通り、都市、州など、ユーザーに関する住所情報が保存されているとすると、ユーザーとの関係が1対多のAddressエンティティを持つのが論理的です。

最後に、正規化のアイデアは、ユーザーに関するさまざまなデータが保存されている場合に優れているため、そのような場合にのみ意味があります。正規化を行うと、クエリのパフォーマンスに余分なオーバーヘッドが発生します。正規化を行うほど、選択クエリの実行速度が低下します。

于 2012-11-24T16:22:40.090 に答える