Download as PDF, PPTX
もうひとつのアンチパターン OTLT、あるいは如何にして私はオレオレフレームワークを忌み嫌うようになったか
- 1.
- 2. 自己紹介 ● 春原 宏保 (すのはらひろやす) ● 3案件を回すフリーランスプログラマー ● PHP + MariaDB (週4日常駐) ● C# + SQL Azure (受託) ● Delphi + SQLite (受託) ● 長野市在住、しかし平日は新宿区住まい ● 苦手なモノ: テストコードを書くこと
- 5.
- 6. こんなテーブル、見たことある? ● コードとその値のペアをテーブルに持ちたい ● 都道府県コードと都道府県名 ● 性別コードと性別名 ●電話番号種別と電話番号 ● etc…
- 7. code name 1 北海道 2青森県 3 岩手県 4 宮城県 5 秋田県 prefectures code name 1 男性 2 女性 3 法人 4 未回答 genders code name 1 固定電話 2 携帯電話 3 FAX telephone_types
- 8.
- 9. code_type code name pref1 北海道 pref 2 青森県 pref 3 岩手県 pref 4 宮城県 : : : gender 1 男性 gender 2 女性 : : : telephone 1 固定電話 telephone 2 携帯電話 コードタイプ コード値 内容
- 10. 人呼んで「One True LookupTable」 ● よく言えばKey-Value Store ● テーブル数が減ってスッキリ! ● ER図もごちゃつかない! ● 新しいコード体系が加わってもテーブルを 増やす必要がない! ● 情報が集約されていて便利! ● SIer、もしくはSIer出身の技術者が好んで 使うイメージ (※個人の感想です)
- 11. code_type code name pref1 北海道 pref 2 青森県 pref 3 岩手県 pref 4 宮城県 : : : gender 1 男性 gender 2 女性 : : : telephone 1 固定電話 telephone 2 携帯電話 あんまりSIerの臭いがしない? ならば──
- 12. kbn kbn_cd kbn_name pref01 北海道 pref 02 青森県 pref 03 岩手県 pref 04 宮城県 : : : gender 1 男性 gender 2 女性 : : : telephone 1 固定電話 telephone 2 携帯電話 これで一気にSIer風味に!!
- 13. テーブル設計のポイント ● kbnは適度な大きさの文字列型で ● kbn_cdは必要十分な大きさの文字列型で ● コード値として文字列を持つコード体系の データが加わる可能性があるため ● コード値が数字であるコード体系のデータは ゼロパディングする(例: 都道府県コード) ● kbn_nameももちろん文字列型で
- 14. いずれテーブル定義の変更が必要に kbn kbn_cd kbn_name errorE01495678B01 予期しないエラーが 発生しました。カス タマーサポートに連 絡してください。 想定より長い kbn_cdが 現れた!
- 15. いずれテーブル定義の変更が必要に kbn kbn_cd sub_kbn_cdkbn_name office japan nagano 長野本社 office japan matsumoto 松本本社 office japan hakuba 白馬支社 office japan karuizawa 軽井沢営業所 区分値の 下位要素が 追加に!
- 16. ほかにも問題山積 ● kbn_cdの制約を設定できない ● 例えばvarchar(5)だとして、都道府県コードの 正しい書式は次のどれ? (_ は空白) • 01___ • _1___ • 1 • 01 ● kbn_cdの定義がvarchar(10)に変更されたら、 都道府県コードの書式も変える? バグの元!!
- 17. ほかにも問題山積 ● kbnの重複登録の危険性 ● genderというkbnがあることに気づかず kbn =sexのデータを投入するとか ● errorというkbnがあることに気づかず kbn = messagesのデータを投入するとか ● こういうミスをなくすため、kbnの管理を エクセル・ホーガン氏に依頼
- 18.
- 19. 私の携わったプロジェクトでは── ● 設計時点においてOTLTありき ● ほかのプロジェクトでもそうやってきた ● 値が何でもかんでも文字列で返ってくるのが 気に入らない (Java1.4でした) 実はそんなことは問題ではなかった
- 20.
- 21. 素晴らしきかな、Mr. Bean ● データベースのカラムの型にかかわらず 返り値はString型 ● OTLTとかどうとかに関係ない ●受け取った値をJava側でその都度型変換 ● データ登録時も当然Stringで渡す ● 二度○ねとか思う
- 22.
- 23. さらに知りたい方は ● データベース技術者のミックさんの記事 gihyo.jp: SQLアタマアカデミー 第3回 「テーブル設計のグレーゾーン～毒と薬は 紙一重(1)単一参照テーブル～ テーブルにポリモフィズムは必要か」 http://gihyo.jp/dev/serial/01/sql_academy2/000301
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30. Eclipseなら、コマンド一発で DAOを自動生成できるよ? (・∀・) カエレ！ ＿ ／- イ､_ ＿＿ ／: : : : : : : : : : : ( 〈〈〈〈 ヽ /: : : : ::;:;: ;: ;:;: ; : : : ::ゝ 〈⊃ } {:: : : :ノ --‐' ､_＼: : ::｝ ∩＿＿＿∩ | | {:: : :ノ ,_;:;:;ノ､ ェｪ ヾ: :::} | ノ ヽ ! ! 、 ｌ: :ﾉ ／二―-､ |: ::ﾉ / ● ● | / ，,･_ | /／ ￣7/ /::ノ | ( _●_) ミ／ , ’,∴ ･ ¨ 〉(_二─-┘{／ 彡､ |∪| ／ ､･∵ ’ ／､／/| ￣￣ヽ / ＿＿ ヽノ / ／ // |／／＼ 〉 (＿＿＿） / / // /＼ ／
- 32.