2016年11月9日水曜日

RDBアンチパターン - 強すぎる依存 -

この記事はPHPカンファレンス東京での登壇資料の補足記事です。
当日の話はこちら。

PHPカンファレンス2016でRDBアンチパターンの話してきた #phpcon2016




第一章の強すぎる依存は要約すると


  • ORMやDBマイグレーションには強い制約と誓約がある
  • ORMやDBマイグレーションによるメリット・デメリットがある
  • ORMやDBマイグレーションを上手く活用するために必要なこと
  • ORMやDBマイグレーションはパフォーマンスによって利用が難しくなることがある
  • 強い依存性があるが依存しすぎると危ない


を話をしました。
特に重要な項目について少し補足します。

■制約と誓約

元ネタはHUNTER X HUNTERです。
一般的にはルールとマナーなどの言葉で置き換えれると思います。
スライドに書かれて居ない大切な事はこの2つを守るメリットです。

制約のメリット

制約は必ず守らなければいけないルールです。
つまり逆説的に制約というレールを轢いてその上を走るということです。
その為、一般的な最適解に辿り着きやすく、よくある事例ならすでに回答が用意されている事もあります。
そのため大きな失敗をする可能性が減り、レールの上を走っているときはとても生産性が上がります。

誓約のメリット

制約に対して誓約は強制力はありません。
例えで出したデザインパターンや命名規則などは強制では無いため、現場では統一されていないこともあります。
また文化として誓約が浸透している部分も多々あります。
例えば命名規則で言えばisで始まればboolを返すでしょうし、getなら戻り値を返すと言った感じです。
これによってコードの記述量が減ることは一般的には少ないと思います。
むしろデザインパターンを採用することで増える事もあるでしょう。
しかしこのような誓約を利用すると人間がコードを読んだり書いたりする際の生産性が上がります。
それは「勘が働く」からです。
メソッドの振る舞いが予測でき、クラス構造が想像出来るコードと出来ないコードで比較すればその差は歴然です。

以上の事からDBの抽象化をするツール群はDB層の本来の姿に対する強い制約と誓約から


  • ORMを意識したスキーマ設計
  • RDBMSを意識したクラス設計


を意識しなければなりません。
しかしその代わりに高い生産性を与えてくれています。
その為、昨今でこれだけ利用されていますし、私も活用しています。

■強すぎる依存の問題

ツール群には強い制約と誓約と引き換えに高い生産性を得ることが出来る事は伝わったかと思います。
しかしこの強い制約と誓約によって問題もあります。

1つ目はスライドにもある通り、RDBの持っているSQLや多くの機能が失う事。
具体的には守る部分では外部キー制約やCHECK制約(MySQLには元々無いけど)などを利用できません。
また型の選択肢も制約されるため、PostgreSQLのJSONB型や範囲型などのより適切な型を選択することも出来ません。
SQLの構文にはプログラムでは表現しにくい内容もあり、それを失うことでパフォーマンスやメンテナンス性を犠牲にすることも多々あります。
このように制約と誓約によってRDBの本来持っている機能を失っている事を忘れてはいけません。

2つ目はDBの抽象化は完全では無いということです。
メリットの部分でも書きましたが設計などで意識しないと効率良く利用できません。
またパフォーマンスによって、利用できなくなることもあります。
そのため、ツール群に依存しているとサービスがスケールアップの壁にぶつかる事があります。
その際に「新しい選択肢を取れるかどうか?」がそのエンジニアの価値につながるというお話も当日はしました。
気になる方は下記の動画をご拝聴いただければと思います。


ということで「強すぎる依存」について説明しました。
アンチパターンというよりは現状のアプリケーションエンジニアとデータベースエンジニアの中にあるギャップを説明した章となっています。
PHPカンファレンスはアプリケーションエンジニアが多く、このような話を聞く機会は少ないと思うので最初の掴みとしては良かったと思います。
またデータベースエンジニアからすると隣の別のレイヤーの話ですからこれを機にもう少し興味を持ってくれると嬉しいですね。

ということで補足としては以上です。
これを見て気になる人はぜひ動画を見てほしいです。
「強すぎる依存」の章だけなら15分程度なのでお時間が有る時に是非。

他の章の説明はこちらから行けます

PHPカンファレンス2016でRDBアンチパターンの話してきた #phpcon2016


登壇動画