open build/reports/life/index.html: #sqlap

ラベル #sqlap の投稿を表示しています。すべての投稿を表示

2013年8月17日土曜日

SQLアンチパターン読書会「EAV(エンティティ・アトリビュート・バリュー)」に参加してきました #sqlap

SQLアンチパターン読書会「EAV(エンティティ・アトリビュート・バリュー)」
http://sqlap.doorkeeper.jp/events/4507

EAV

この回は、私が概要の説明をするお役目を承ったので、いろいろと調べてみてみました。

属性とその値を対象に関連付ける場合、その属性について詳しく調査出来るかがこのアンチパターンを解消する鍵なのではないかと思いました。
解決策もORMでサポートされているものも多く、カタログのように属性がバラバラであったりする場合はRDBMSでは難しいということも知りました。
また、最近ではNoSQLのような解決策も出てきており、どうしてもRDBMSでは難しい場合は選択肢として選べるようになったのは大きいと思いました。

おわりに

主催の@natsu_nananaさん、参加者の皆様、会場を提供してくださった株式会社アルティネット様ありがとうございました。
次回もまたよろしくお願いします。

2013年6月19日水曜日

SQLアンチパターン読書会「キーレスエントリー」に参加してきました #sqlap

SQLアンチパターン読書会「キーレスエントリー」
http://sqlap.doorkeeper.jp/events/4356

はじめに

今回は、「キーレスエントリー」が対象でした。
これまで外部キーのないプロジェクトばかり参加しており「キーレスエントリー」のデメリットを丸々抱えていたので、どのようにしたら改善できるのかを知るきっかけになればいいなと思い、参加しました。

SQLアンチパターン読書会　4章　キーレスエンエントリ（外部キー嫌い） from makopi 23

今回のアジェンダは@makopi23さんが発表してくださいました。
ありがとうございました。

ディスカッション

外部キー制約を貼らない理由として上げられていた、テストデータについてはDB毎に実装されている機能を用いて制約を遅延することができます。

MySQLの場合

13.5.6.4. FOREIGN KEY 制約
http://dev.mysql.com/doc/refman/5.1/ja/innodb-foreign-key-constraints.html

PostgreSQLの場合

SET CONSTRAINTS
http://www.postgresql.jp/document/9.2/html/sql-set-constraints.html

既に外部キー制約が無い場合は、データクレンジングを行い、外部キー制約を貼るのが望ましいですが、コストとの兼ね合いがあるのでやるべきとは言えないというのが、現状ではないかと感じました。

外部キー制約を外すのは、ハイパフォーマンスを得るために已むを得ない場合や、シャーディングをする場合などで、単一のDBを扱うような場合は、初めから付けておくのが必須であるということでした。

DBのマイグレーションや、DDLの作成方法など、モデリングとDBの周辺のお話もいろいろと聞けて、勉強になりました。

おわりに

次回の「EAV(エンティティ・アトリビュート・バリュー)」では、アジェンダを担当することになりました。
「EAV」は、身近なアンチパターンでもあるので楽しみです。

主催の@natsu_nananaさん、参加者の皆様、会場を提供してくださった株式会社アルティネット様ありがとうございました。
次回もまたよろしくお願いします。

2013年5月26日日曜日

SQLアンチパターン読書会「続・IDリクワイアド」に参加してきました #sqlap

SQLアンチパターン読書会「続・IDリクワイアド」
http://sqlap.doorkeeper.jp/events/3968

はじめに

今回は、前回の「IDリクワイアド」が終わらなかったので、その続きを行いました。
始まる前に@osa2さんが下調べをして下さったLTのお陰で後のディスカッションであまりブレずに出来たのではないかと思いました。
ありがとうございます。

ディスカッション

IDリクワイアドのアンチパターンで重要なことは「キー戦略」であることだと感じました。
@osa2さんのスライドで使われていた、達人に学ぶDB設計徹底指南書の「第8章　論理設計のグレーノウハウ」にて代理キーを使うのはグレーノウハウであるということが紹介されていました。

USINGやJOINの使い方では、自分が普通だと思ってたことが、実はオプティマイザが進化してて別にその書き方じゃなくても大丈夫だということを知りました。
特定のプロジェクトやレガシーコードにしか携わっておらず、新しいことに触れる機会が少なくなるのは、プログラマにとっては損失ではないかと思いました。

日本特有の悪しきウォータフォールが蔓延り、実装段階でテーブルを増やしたり減らしたりすることが出来ず、設計の機会があったとしても論理設計を経ずに物理設計から始めてしまうため、こういった傾向に陥りやすいのかなと感じました。

おわりに

この勉強会は副読本があるとより実践に近いディスカッションが出来るということが実感しました。
次回の、「キーレスエントリー」は、ページ数こそ少ないですが、一般的にありがちなパターンだと思われるので、これまで紹介された本を読んでみたいと思います。

主催の@natsu_nananaさん、参加者の皆様、会場を提供してくださった株式会社アルティネット様ありがとうございました。
次回もまたよろしくお願いします。

2013年5月23日木曜日

SQLアンチパターン読書会「IDリクワイアド」に参加してきました #sqlap

SQLアンチパターン読書会「IDリクワイアド」
http://sqlap.doorkeeper.jp/events/3774

はじめに

今回は、SQLアンチパターンでも言及の多かった「IDリクワイアド」でした。
個人的には、考えなしにIDつければいいやとなったことはなかったので、どのような状況になったら、このアンチパターンが発生するのかが知れたらいいなと思っていました。

ディスカッション

RDBMSに関しての様々なキーについてどのようなものがあるのかや、それぞれのキーをどのような場合に適用するのかを教えて頂きました。

また、このアンチパターンでありがちな場合は、某オフィススイートの表計算ソフトの考え方をそのまま適用してしまうためということでした。
個人的には、コードのサンプルなどでIDとしか振っていないテーブルを正しいと思い、テーブルにIDを必ず付けて使ってしまうのではないかと思いました。

画面から始めると、データの設計が蔑ろにされやすい。そのツケを長年支払うはめになる。 #sqlap
— とーますさん (@grimrose) 2013年5月9日

アプリケーションのコードよりDBのデータの方が寿命が長いので、気を配って設計しなければいけないということでした。
特に画面は変わりやすいのでそれを元に設計してしまうと、残念な意味での「継ぎ足された秘伝のソース」になってしまうのだなと学びました。

では、どんなモデリングをしたらよいか良いサンプルはなかということで、教えてもらったのがDatabase Answersです。

例えばTutorial on Beginning Data Modellingを見てみると、どのようにエンティティとリレーションが成り立っているのかが見えてきますし、Industry Data Modelsを見てみるとどこかで見たことがあるようなモデルがあります。
とても参考になるので、設計を始める前に似たようなモデルはないか探してみるのといいと思いました。

あと、IPAのデータベーススペシャリスト試験(DB)の午後2の試験についていろいろと勉強になるという話もあったので調べてみたいと思います。

おわりに

脱線は脱線でいろいろな話が聞けたのはよかったのですが、出来る限り内容に即したディスカッションが出来るといいのかなと思いました。

主催の@natsu_nananaさん、参加者の皆様、会場を提供してくださった株式会社アルティネット様ありがとうございました。
次回もまたよろしくお願いします。

2013年5月7日火曜日

SQLアンチパターン読書会「ナイーブツリー」に参加してきました #sqlap

SQLアンチパターン読書会「ナイーブツリー」
http://sqlap.doorkeeper.jp/events/3682

はじめに

前回のレポートはこちら→SQLアンチパターン読書会「ジェイウォーク」に参加してきました #sqlap
今回は、「ナイーブツリー」ということで自分自身経験した内容が話せればいいなと思い、参加いたしました。
ツリー構造に馴染み深い掲示板に関する事を自己紹介と併せて話しましたが、ニフティサーブから近年のSNSまで幅広く、世代というものを実感しました。

ディスカッション

アンチパターンを使っても良いとして上げられたCTE(共通テーブル式)が使えるDBであれば、シンプルでテーブルも少なくて済むということでした。
今回の解決策として上げられた3つのパターンについてですが、経路列挙モデルの場合、DBによっては型が用意されていたりして人間にも扱いやすいのですが、デメリットとして前回のジェイウォークに当てはまってしまうので、アプリケーション側で制約を守るようにしなければならないことです。
次に入れ子集合モデルでは、データの変更より参照が多い場合に使われることが多く、ORMによってはプラグイン等でサポートしているものもあるそうです。
デメリットとしては、ツリー構造の欠損等が発生した場合、人間で修正するのがとても難しいということです。
閉包テーブルモデルでは、入れ子集合と同様に変更より参照が多い場合に利用する場合が多く、2つテーブルを利用することがメリットでありデメリットでもあるということでした。
ツリー構造のスケールによってどのモデルを採用するかを検証し、コストに見合ったものを選ぶのが望ましいのではないかと思いました。

私の場合、組織階層を表現する方法として経路列挙モデルを採用しました。対象となる組織の階層も深くなく、横の広がりもそれほど大きいものでは無かったためです。
経路列挙のデメリットとしてはジェイウォークと同様にインデックスが使えないことです。ですが組織の数そのものが少ないため、デメリットがそれほど目立ちません。
もし今後階層がもっと深くなったり、横に広がるような場合は、残りのモデルやCTEを検討する必要が出てくるかもしれません。

今回のツリー構造をRDBMSでどのようにしたらよいのかについて、@t_wadaさんからJOE CELKO氏が書かれた本を紹介して頂きました。
1冊まるごとツリー構造について書かれた本らしいので、もう少し巨大なツリー構造に立ち向かう前に読んでみたいと思いました。

#sqlap プログラマのためのSQL 第4版ジョー・セルコ amazon.co.jp/dp/4798128023/… @amazonjpさんから
— とーますさん (@grimrose) 2013年4月25日

同じくJOE CELKO氏が書かれた本として上記の本があるそうなので、こちらの本も取り寄せたいと思います。

#sqlap 監訳注SQLアタマアカデミー：第6回　SQLで木構造を扱う～入れ子区間モデル　（1）もしも無限の資源があったなら#gihyojp bit.ly/LI82s0
— とーますさん (@grimrose) 2013年4月25日

入れ子集合の監訳注にあった入れ子区間モデルは、ここが参考になると思います。

おわりに

次回の「IDリクワイアド」は、ORMとの関係でいろいろと物議を醸した章なので、楽しみです。

主催の@natstu_nananaさん、参加者の皆様、会場を提供してくださった株式会社アルティネット様ありがとうございました。
次回もまたよろしくお願いします。

2013年4月24日水曜日

SQLアンチパターン読書会「ジェイウォーク」に参加してきました #sqlap

SQLアンチパターン読書会「ジェイウォーク」
http://sqlap.doorkeeper.jp/events/3416

はじめに

SQLアンチパターンの読書会が開催されるとのことでしたので、申し込みました。
自分が経験していなかった話を聴いたり、逆に自分が経験したパターンについて他の人がどういう対処をしてきたのか知りたいと思ったのがきっかけです。

ジェイウォーク

読書会とは言うものの読んでくる前提でしたので、ディスカッションが主な内容でした。

ジェイウォークに陥る要因として上げられたのが、以下の通りでした。

そもそも、交差テーブルを作るということを知らない。
テーブルを追加するには、いろいろと手続きが必要。

一対多から多対多へ変更が生じた場合は、キーとなる属性同士で関連付けるので、ジェイウォークのようにしてしまうと、検索時にインデックスを利用しないため、遅くなりがちです。
なので、そういう匂いを感じたら、交差テーブルを導入するのが正しいということを知りました。

一対多が多対多になる可能性が予見されるのなら、交差テーブルを必ず使うこと。at ジェイウォーク #sqlap
— とーますさん (@grimrose) 2013年4月11日

解決策の交差テーブルを導入するのが望ましいのですが、既にジェイウォークになっていた場合は、どのように解決したら良いかという疑問については、@t_wadaさんがデータベース・リファクタリングの本を用いて解説したくださいました。
トリガーを用いて新しい交差テーブルへデータを同期して、アプリケーション側で経過措置を講じ、最終的に交差テーブルを利用するように変更するといった内容でした。
DB周りについて体系的に学習したことがなかったので、こういった対応が出来るということ自体知りませんでした。
また、交差テーブルについても、関連付けられた日付などキー以外の項目が必要になってきたりして単なる交差テーブルからエンティティへ変化してしまうこともあるので、テーブルを設計するのはやはり難しいと感じました。

おわりに

今以下のジェイウォークは、本の始めの方にあるので容易に感じてしまいそうですが、解決策の先がまだあり奥深いものだと実感しました。
また、@t_wadaさんにSQLに関して参考になる書籍を教えていただいたので、一つづつ取り寄せて見たいと思います。
次回は、ナイーブツリーということで、自分の経験した内容でもあるので、楽しみです。

主催の@natsu_nananaさん、参加者の皆様、会場を提供してくださった株式会社アルティネット様ありがとうございました。
次回もまたよろしくお願いします。

2013年3月1日金曜日

SQLアンチパターン・レトロスペクティブ - データベース危篤患者の救出 - に参加してきました #sqlap #devlove

SQLアンチパターン・レトロスペクティブ　- データベース危篤患者の救出 -
http://devlove.doorkeeper.jp/events/2775

SQLアンチパターン・レトロスペクティブ - データベース危篤患者の救出 - #sqlap #devlove
http://togetter.com/li/462950

はじめに

先月に発売された「SQLアンチパターン」の監訳者お二人による勉強会が開かれるということで、参加してきました。

参加するまでの経緯としては以下の様な感じです。

まず、本自体は出た当初に購入してました。
その後にJUnit実践入門の読書会があり、急遽和田さんが参加されてその時にサインを頂くことが出来ました。

ラゾーナでラス1のSQLアンチパターン購入done. #sqlap
— とーますさん (@grimrose) 2013年1月27日

デブサミ2013でも講演をされていたのですが、その時は短いセッションだったので物足りない感じがしてました。

2013/02/15 デブサミ2013【15-B-5】SQLアンチパターン - 開発者を待ち受ける25の落とし穴 #devsumiB
http://togetter.com/li/451569

2/21には、監訳者お二人の刊行記念トークセッションがありましたが、都合がつかず参加することが出来ませんでした。

書籍『SQLアンチパターン』に関するつぶやきまとめ #sqlap
http://togetter.com/li/459889

アンチパターン

私個人が経験したアンチパターンは、以下の項目です。

ジェイウォーク（信号無視）
キーレスエントリ（外部キー嫌い）
EAV（エンティティ・アトリビュート・バリュー）
ポリモーフィック関連
ファントムファイル
フィア・オブ・ジ・アンノウン
アンビギュアスグループ

この本では、よかれと思って裏目に出てしまうもの、それをアンチパターンとして呼ぶ #devsumiB #sqlap
— とーますさん (@grimrose) 2013年2月15日

遭遇した当時はベストだと思っていても、後からその代償を払うことになってしまい、いろいろと大変でした。

SQLやDBは言語によらず利用している人が多いためか、SQLアンチパターンに挙げられている事例を経験された方が多かったみたいです。

個人的に26番目のアンチパターンとして挙げるとしたら、コンソールからテストされていないDDL・DMLを実行してしまう行為です。
いい名前が思いつかなかったので、仮に「グレネード・キッカー」とでもしておきます。

おわりに

この本は、過去に行った罪を懺悔し、悔い改めることで現実と折り合いをつける方法を学ぶことが出来るという点で、救いがあるのではないかと思います。
よく聞く「若いうちの苦労は買ってでもしろ」は、先人の失敗や経験はこういった本を買うことで学ぶことが出来るのだから、同じ苦労をなぞるのではなく、その先の未知の領域で苦労をしたほうが良いということでは無いかなと思いました。

終了後、監訳者のもう一人である和田省二さんからサインを頂くことが出来ました。

エンティティを設計したり、仕様変更がテーブルに及ぶときに、この本を片手にどのように対処すればよいのか考えて、バランスのとれた最善の対処が出来るようになりたいと思います。

主催者であるDevLOVEのスタッフの皆様、監訳者お二方、参加者の皆様、会場を提供して下さった株式会社インターネットイニシアティブ様、ありがとうございました。

登録: 投稿 (Atom)