テーブル構造と検証

Question

テーブルの従業員がいて、プライマリキー/テーブルを定義するための提案が必要でした。最初はEMP IDフィールドを主キーとして保持したいと考えていましたが、従業員のすべての変更（TL Name）を追跡したいと思います。この表では、1つのユニークなアクティブなEMP IDのみを許可する必要がありますが、複数の非アクティブを許可することができますEMP ID。提案してください。

以下は、テーブルの構造例です。

+----+--------+----------+---------+-----------+ 
| ID | EMP ID | EMP Name | TL Name | Is Active | 
+----+--------+----------+---------+-----------+ 
| 1 | Z001 | Raj  | Vik  | No  | 
+----+--------+----------+---------+-----------+ 
| 2 | Z002 | Ajay  | Peter | No  | 
+----+--------+----------+---------+-----------+ 
| 3 | Z001 | Raj  | Ashish | No  | 
+----+--------+----------+---------+-----------+ 
| 4 | Z003 | Soni  | Suresh | Yes  | 
+----+--------+----------+---------+-----------+ 
| 5 | Z001 | Raj  | Vinod | Yes  | 
+----+--------+----------+---------+-----------+ 

Answer 1

i）テーブルでIsActiveルールを使用すると、EmpIDをプライマリキーにすることはできません.hvでコードを作成することはできません。

ii）IsAcTiveルールを削除すると、EmpIDがコードで生成され、同じコード内に1つのfilter.soを置くことができると思うので、それを主キーとしています。

より良いCIを作成します。 iii）IDをPKにします。

iv）それらの多くは同じデザインパターンに従います。そのテーブルが100万レコードに拡大し、検索や参加に非常に頻繁に使用される場合は、間違いなくデザインが間違いです。

これが当てはまる場合は、変更表と削除列を別々に保管してください。

v）あなたのテーブルが小さくても、すべてのクエリでisAtive = 'YES'と書く価値がありません。

vi）別々のテーブルを保つには、コードと保守がもう少し必要ですが、それは価値があります。