あなたは、テーブルを作成したい場合は、必ず以下の提案を参照すること。
- 企業IDの データ型はnvarchar 40このデータは、どの会社であります
- CompanyFullName [省略可能] のnvarchar会社名40を
- DepartmentIDの nvarchar型40は、このデータは、どの部署であります
- [省略可能] DepartmentFullNameのこの部門はnvarcharの名前40
- STAFFIDの データ型はnvarchar 40労働者の名称データ
- [省略可能] StaffFullName 従業員40のnvarchar型の名前を
もちろん、上記の表の設計、支配的なイデオロギー。
1.通常の従業員は、データのみが他の人を見ることができない、自分自身のデータを見ることができますが、他はデータを変更することはできませんし、
この時間は、データがStaffIDそれによってフィルタリングすることができます。
2.自分の部署の頭は、それがDepaertmentIDによってフィルタリングすることができ、データを見ることができます。
3.会社の経営者は、企業IDによってフィルタリングすることができ、自社のデータを見ることができます。
もちろん、いくつかのいくつかの簡単なシーンよりも、だけでなく、より複雑な場合、
例えば、Aは、データB、Cを見ることができ、その後、問題を解決するために同様のStaffID IN（「A」、「B」）を使用します。
StaffIDは、差ユーザーIDで、スタッフの表現は、会社の正社員です。
ユーザーIDは、システムのユーザーを表し、これは、同社の従業員ではないかもしれません、顧客であってもよいです。
一部のソフトウェア設計者は、プログラムの設計は、いくつかは、たとえば、あなたは言うでしょう、安全のためにしたくない企業IDを、のDepartmentIDはから入手できます
StaffIDはもちろん、計算することができたもの、フルネームそれらはまた、上記の計算を介して利用されている、データが考慮のこの方法に従って得ることができる
問題を、我々はデータの冗長性の多くを持っています。
私たちは、私は寧波ブルーテクノロジー、自宅で躊躇の理由で働くために使用したもの、と思い、私は仕事の杭州支店を動員するために、1年以上仕事、私の
同じグループ会社で個人IDは、変更はありませんが、私の会社は部門が変更された、変更された、以前のデータは寧波会社に属し、
企業、部門間、さらには借りスタッフ動員人員移動度の杭州の会社とモビリティにしていない非常にあります広範な問題。
時々 、また、非常に動揺SQL文を記述するために他の関連データを取得するために他のテーブルを保持したテーブルでのビジネスデータの多くは、この時間、および
部署名、ユニットの名称も変更される可能性があり、以前のデータは、その名前の部署が、彼らはまだそれを保持し、あなたもできるデータである
私たちは、SQLあいまいクエリを記述は非常に便利です、と私たちのアナロジーグループ全体のデータがに合わせて、そのような統一されたデータセンターとして、寧波に保存されている
など、当社グループ全体の組織構造従業員情報、権限を割り当て、ワークフロー構成、当社のローカルビジネスデータベースには、部門、スタッフのテーブルではありません。
このような状況の下で、一度部門のスタッフの名前を保つ必要があること、それは非常に適切です。
ます。https：//my.oschina.net/iwenr/blog/227673で再現