DataBase?

まずは人事基本情報データベースの構成を考えて行きたいと思っています。

20100211

emp.cld.20100211.jpg

20100210

emp.cld.20100210.jpg

備忘

  • つまるところ履歴テーブルの集まりだ -- felix 2010-02-08 (月) 13:32:30
  • 共通の履歴テーブルとしてまとめれば、テーブルはシンプルになる -- felix 2010-02-08 (月) 13:32:56
  • やりすぎると同じテーブルばかり出てきて逆に複雑になるか? -- felix 2010-02-08 (月) 13:33:18
  • 社員履歴とコードの履歴は分けよう -- felix 2010-02-08 (月) 13:33:57
  • 社員個人情報履歴と発令履歴は分けるのが一般的だ -- felix 2010-02-08 (月) 13:34:19
  • 発令履歴は、コード選択結果の履歴となる。組織コード、役職コード、雇用形態コードなどなど。ほとんどはコードだ。 -- felix 2010-02-08 (月) 13:35:19
  • 逆に社員個人情報履歴は、任意の文字列の変更履歴となる。氏名、住所、メールアドレス等々 -- felix 2010-02-08 (月) 13:36:10
  • さらに個人情報履歴は、複数の任意の文字列を一まとめにして履歴を作るべきだ -- felix 2010-02-08 (月) 13:36:53
  • となると、社員個人情報と発令履歴は別個の考え方になるはずだ。 -- felix 2010-02-08 (月) 13:37:36
  • もしくは、それらは、単に履歴の性質の問題であり、コードの履歴と任意のテキストの履歴を分けるべきかもしれない。 -- felix 2010-02-08 (月) 13:38:52
  • それら二つの性質の履歴テーブルに対して、個人情報であるか、発令であるかの区分わけをしておく -- felix 2010-02-08 (月) 13:41:46
  • コードにももちろん履歴がある。コードの履歴テーブルは、補足事項が多いのでフィールド数が増えるはず。なので、別テーブルが望ましい。 -- felix 2010-02-08 (月) 13:43:09
  • その中でも、必須の組織コードをテーブル分けすべきか悩む -- felix 2010-02-08 (月) 13:43:44
  • 暦が無いほうが管理しやすいコードもあるが、厳密には少数だ(性別とかね)。いっそ全てのコードは暦管理してしまえば、コードのテーブルは非常にシンプルになる -- felix 2010-02-08 (月) 13:47:00
  • 社員コードは、変動する暦管理の対象とすべきだ。会社によっては、社員コードが変動したり、使いまわしたりすることがありえるからだ。 -- felix 2010-02-08 (月) 13:47:56
  • そうなると、社員は、内部的には社員ID(KEY)で管理される。 -- felix 2010-02-08 (月) 13:48:38
  • 社員ID(KEY)の組成は、もちろん一つのテーブルで行われる。ここで社員が作られるのは、入社・・・ いや、採用エントリー開始であるはずだ -- felix 2010-02-08 (月) 13:50:07
  • 採用エントリー日の組成のテーブルが社員テーブルとなる。ここには、入社日も管理しようか -- felix 2010-02-08 (月) 13:52:24
  • 退職日などは、同じようには管理しない。退職、出向、休職復職、再雇用(定年後含む)は、発令履歴でおこなうべき問題だ。 -- felix 2010-02-08 (月) 13:53:10
  • そうか・・・ コード、任意のテキスト、の暦の他、 日付、数字 自体を暦としなくてはならないことがある。 -- felix 2010-02-08 (月) 13:56:31
  • たとえば、休職日、復職日 などは、日付の暦を管理するものだ -- felix 2010-02-08 (月) 13:57:29
  • 発令暦に数字を暦管理すべきものがあるかなぁ・・・ 評価や適正試験は、これまでの議論とはまったく違うテーブルが必要である気がする。 -- felix 2010-02-08 (月) 14:01:59
  • まぁ 数字はなにかあったような気がする。それでいくと、履歴テーブルは、メインとなるデータ型別に『任意のテキスト』『コード』『日付』『数字』とするものに分けれそうだ -- felix 2010-02-08 (月) 14:05:07
  • それらの履歴を総括しておくものとして、履歴登録理由区分(発令種別、個人情報異動種別)のようなテーブルを作ろうか? 各々(発令・個人情報異動)の大本になる履歴テーブルで、その他の履歴の開始日については、すべて共通でこの履歴が作られる。 -- felix 2010-02-08 (月) 14:08:31
  • テーブル型は、社員情報履歴(発令・個人情報履歴)はinnodbだろうと思う。その他、固定的なコードについては、myisamだろうけど。任意テキスト、日付の履歴テーブルはinnodbとなるのか? ミックスするとバックアップが厄介と聞いているが、人事システムなら、夜間とめてもかまわないからOKだろう -- felix 2010-02-08 (月) 14:12:32
  • アプリ上の単票閲覧、修正はこのままでOKだが、一覧は、耐えられる見方にならない。それはそれで考えよう。アプリ上で必要な一覧は、用途別に固定はできるはず。 -- felix 2010-02-08 (月) 14:14:43
  • 権限設定については、まったく考えられない。アプリのビューについては、フレームワークに任せればよいが・・・ 会社という概念もアプリ上でなんとかなるだろう。(他の会社がみれる。みれない。) 問題は、レコードに対するものだろうね。コードマスタと各々のトランにアクセス制御のフィールドを追加しておくか・・・ -- felix 2010-02-08 (月) 14:20:19
  • レポジトリ作成するか・・・ -- felix 2010-02-10 (水) 22:32:23
  • マスタに歴管理の有り無しを同じテーブルで管理するのは、断念。思考がついていかない。 -- felix 2010-02-11 (木) 00:02:47
  • マスタに ex_text_01 _02 とある部分は、別テーブルのレコードとして管理すべきなのだろうか?そこも思考がついていかない。 -- felix 2010-02-11 (木) 00:04:14
  • _01 _02 としてしまうと、アプリの処理が増える・追加がしにくい。というデメリットがあるが、SQL上はわかりやすい。 -- felix 2010-02-11 (木) 00:06:06
  • 実際のテーブルを書いていくと、また 考えが変わるだろう。  -- felix 2010-02-11 (木) 00:06:31
  • 日付データの初期値は、2299/12/31 とするか・・・・。 -- felix 2010-02-11 (木) 00:24:48