0

私は現在、私たちの学校の新しいデータベース/Web アプリケーションを開発しています。私の質問をもう少し関連性のあるものにするために、少し背景情報を提供する必要があります。

このアプリケーションにアクセスするさまざまなユーザー タイプがあり、それぞれがアクセスできる「ゾーン」ごとに異なるアクセス許可でアプリケーションのさまざまな部分にアクセスする必要があります。

例えば：

学生はログインしてそこにある情報にアクセスし、詳細を更新したり、レポートのコピーをダウンロードしたりできます (そのため、学生は自分の情報のみを表示できます)。

教師はログインして、そこにある情報と彼らが教えるすべての生徒にアクセスできます

マネージャーはログインして、管理しているすべての教師と生徒の情報にアクセスできます

他にもたくさんのログインタイプがありますが、この質問ではそれらはすべて、技術的には、追加情報のために独自のテーブルを持っていない、または必要としないより多くのユーザーであるため、それほど重要ではありません.

大部分は自分が満足している構造を決定しましたが、次のようにするのが最善だと思う方法について考えを変え続けています。

関連するすべてのユーザー情報（ユーザー名、パスワードなど）が保存されているユーザーテーブル（User_T）があります。

ただし、一部のユーザー タイプ (EG、学生、スタッフ、ETC) 用に別のテーブルも用意しています。学生はスタッフ メンバーとは異なる情報を保存する必要があるため、これが必要です。ここに私の問題があります。すべてのユーザーが同じ基本フィールド (名、姓、生年月日、性別など) をいくつか持っています。

これらを User_T テーブルに格納する必要がありますか? それとも個々のテーブルで？

それらをすべて User_T テーブルに保存すると、アプリケーションが情報を取得して更新できるようになりやすくなります。たとえば、学生の詳細を表示するときは、User_T を参照して学生の名前などを取得する必要があります。 .

私は現在、最良のオプションは、すべてのフィールドを含む個別のテーブルを作成し、それらをビュー User_V に結合することであり、データの起源を示すフィールドを使用して、更新が実行されたときにそれを適用できるようにすることだと考えています。適切なテーブル。

考え？

4

1 に答える 1

0

User_T テーブルを一般的な「人」プロファイル テーブルとして使用し、他のテーブルを一意の役割固有のデータとして使用することで、適切に分離できるように思えます。User_T は人物に関するより一般的な情報を格納し、このテーブルの ID はおそらく、他のテーブルの「person_id」と呼ばれる外部キーになります。

このテーブル スキーマを使用するかどうかは、この共有された一般的なデータを一緒にクエリする頻度にも依存します。たとえば、タイプ/役割 (スタッフ、学生など) を知らずに名前または電子メールを検索する場合は、この一般的な人物情報を他の情報とは別に User_T テーブルに含めることをお勧めします。ロール/タイプがわかっている場合は、対応するテーブルを選択して検索し、必要に応じて User_T データに JOIN することができます。しかし、このようにテーブルを分離しないと、VIEW または UNION を使用して、単一のクエリで一般的な列のみを検索できるようになります。これは、私の意見では、最適化がはるかに面倒です。

    User_T table: id, first_name, last_name, email, gender, birthdate, role, ...
    Students table: id, person_id, gpa, ...
    Staff table: id, person_id, staff_type, hire_date, ...
于 2013-05-22T01:45:13.843 に答える