私は質問がありますが、現在はデータベースが少しずつ自分自身で学習しています。テーブル内に継承を実装するかどうか
私はコンピュータ小売店があり、ストアは個人サービス（マネージャ、管理者、ベンダーおよびサポート）とクライアント（自然と法律）にあり、これらのすべてには特権を持つユーザー名とパスワードが必要ですアクセス（ユーザー、サービス担当者）。
デザインとしては？私が欲しいのは、アクセス権を管理して、テーブルの継承を避けることですが、PERSONと呼ばれるテーブルやSALESと呼ばれるテーブルから、私の場合やAccessのみで適用する必要はありません。売り手と他の1人のスタッフは、テーブルで何かを購入するユーザーです。セール私は売り手の人員とはしごのデータを保存したい、そして、あなたはPERSONと呼ばれるテーブルが1つだけあれば、その二人の関係は？ ID人ですか？
良いモデルでは、無限大1、無限無限大、1対1の関係を考える必要があります。 ので、良いモデルでなければなりません：
無限の無限のために（1人は、1種類以上を持っていることができます）：
PERSONS
- Person_ID
- Firstname
- Lastname
- Address
WORK
-Work_ID
-Kind (Administrator, seller, etc)
REL_PERS_WORK
-Rel_Id
-Person_ID (from PERSONS table)
-Work_ID (from WORK table)
あなたが言うなら、もし私が人にシステムにアクセスするためのユーザー名とパスワードを持たせたいのであれば、テーブルPERSONを置くか、別のものを作成しなければならないかテーブルと1対1でリンクされたテーブルPERSON –
1人または複数のユーザー名でアクセスできると思うかどうかによって異なります。テーブルを正規化することをお勧めしますが、それを非正規化することも有効です。クエリ1つのテーブルは、2つのテーブルよりも迅速かつ効果的です。 1-1の場合、別のエンティティではないため、同じテーブルを使用します。近い将来、ユーザー名、パスワード、ポイント、ニックネームなどを含むテーブルなど、この情報を分割する場合もあります。主なアイデアは情報を繰り返さないようにすることです。 –
「良い」方法や「悪い」方法はありません。それはあなたのオブジェクトの柔軟性と効果的な手順に依存します。別のケースでは、パスワードをMD5暗号化形式（または任意のONE-WAY方式）で、別のテーブルに格納します。これは、ストアドプロシージャから毎回ソフトウェアから直接問い合せることはありません。私は決してIDのためにこれまでパスワードを問い合わせていません。 –
だけでなく、あなたが冗長なデータストレージを好きではない場合にのみ、テーブルごとに重要なデータを保存し、参加してそれらを結合することがあります。たとえば、もしあなたが大掃除することができるビューを使用することを容易にするために。自然な結合を使用してテーブルを結合します。その上にちょうど私の2セント:) – Hajo