優秀な2人が退職

年度が変わるタイミングで退職する人は多いですが、一緒のチームでやっていた2人も4月いっぱいで退職します。

2人はプランナーとプログラマーで、とても優秀な人です。

次も一緒にやれればと思っていたので残念ですが、思うことはあるので本人たちとまた話そうかなと思います。

Pocket

Posted in 日記.

2014年度開始

4月1日から新年度ということで、僕ももれなくその影響を受けてます。
2013年度の所属していたチームが解体になり、新チームに移ります。

前のチームはリーダーが本当にひどく大変な思いをしましたが、今回のチームはリーダーが優秀なので面白くなるといいなと思います。

技術的なところでいくと、UnityとJava(Servlet)とPHPを触っていく予定です。

Pocket

Posted in 日記.

達人に学ぶDB設計徹底指南書読んだ

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ
達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

読んだ。
リレーショナルDBの設計に関して書かれた本。

論理設計:エンティティの抽出、リレーションの定義、正規化
物理設計:テーブル定義、インデックス定義、ハードウェア、RAID、バックアップ、復旧

こういったことに関して基本的なことが網羅されている。特に多いのは正規化の話。
また、トレードオフに関してもよく書かれている。

正規化に関して言えば、この本の結論としては「第3正規化まではやりましょう。」ということ。
正規化のトレードオフとしてパフォーマンスの問題点にも触れたうえで、パフォーマンスのための非正規化の手法も紹介されているが、「非正規化は最終手段なので、あくまで正規化をやりましょう。」ということ。

あとは、「論理設計のバッドノウハウ」「論理設計のグレーノウハウ」という章が特徴か。

「テーブルをつくるときは主キーになるid列を必ずもちましょう」と教わったり、そもそもフレームワーク(ORM)としてid列をもつことを推奨しているものを使ってたりして、全てのテーブルにid列を持つのが自分のなかでは習慣になっていたが、この本ではそれをグレーノウハウだとしている。
自然キーで解決できる場合はそれを使うべきということ。

例えば、users : user_action_logs = 1 : n の関係のテーブルがある。

users
- id
- name
- age
primary (id)

user_action_logs
- user_id (FK)
- action_time
primary (user_id, action_time)

※(FK) = 外部キー

user_action_logsはユーザーの行動履歴を保存するテーブルだとして、主キーはuser_idとaction_timeみたいな風にしましょうという話。
id列を持ちましょうというグレーノウハウを用いるとuser_action_logsは以下のようになる。

user_action_logs
- id
- user_id (FK)
- action_time
primary (id)

なかなか難しい話でした。

Pocket

Posted in 日記.