「もうDBはこうなってますので」はもったいない

DB設計のアプリ最適な作業

引用記事:「アプリ寄りなDB設計者、インフラ寄りなDB設計者」
※こちらの記事の内容を前提とします。

「データベース物理設計」と聞くと、
どんなことを想像しますでしょうか?

大抵の人は、
データ型などを決定し論理モデルから物理モデルを作成して、
データ容量やその他パラメータなど、
インフラ的な調整をする設計と考えるでしょう。
まあ、それで正しいわけです。とても大事な作業です。

自分はこの「物理設計」に、
「アプリでの開発のし易さのための調整」を入れたい、
と考えています。

DB設計のインフラ最適な作業はかなり一般的な概念で
忘れられることはないですが、
「DB設計のアプリ最適な作業という概念」は、
あまり一般的とは言えないような気がします。
(物理設計が違和感あるなら別に他でもいい。
とにかくその概念がどこかに必要)

何を言っても、もう変えられません

現場でよく見掛けた(もしくは伝え聞いた)一つのある現象があります。
DB設計をする組織と、アプリを開発する組織が別になっていて、
(会社が別だろうが同じだろうがビジネス心理的に距離が遠い状況)
開発側に、

「DB(テーブル設計)はこうなっています。
何を言っても、もう変えられません」

という状況でDBが提供されることが珍しくないように思えます。
(DBFluteユーザの中でもよく話題になり、みんな苦労してるようで)

まず、
レガシーシステムが関連して全くDBを変えられない、
ってのは仕方がないです。当然のことです。

さて、そうでない場合(新規システムやDB変更可能な移行システム)、
引用記事にて書かれたことが、
DB設計時に本当に処置されている(た)でしょうか?

 o アプリ・インフラとのバランス調整(意識合わせ)
 o 自分(DB設計者)の不得意な領域に対するアプローチ

しかし実際には、

「インフラ的には最適だが、
アプリで実装する上では開発効率を落とすようなDB設計」

が、珍しくないような気がします。

ただ、難しいのはよく承知しています。
設計時にはまだプロジェクトに開発側の人間が
全く参加してないなど、
色々システム開発には都合が付き物です。
確かに難しい。

なので、それだけに、
「DB(テーブル設計)はこうなっています。
何を言ってももう変えません」
という状況は、
「DB設計者自体にとってもったいない」と考えます。

DB設計のお客様は?

こないだインテリアデザインの人を特集したTV番組を見ました。
商品を映えさせる店舗デザインですごく評価の高い方の話でしたが、
印象的だったのが「お客様の目線になりきる」という言葉でした。
結構ありきたりの概念なのですが、
やはりそこが「究極の基本」なんですね。

また、お客様の目線を得る方法はもう一つあります。
アンケートや問い合わせなどのフィードバックです。
全ての要望は満たせないにしてもその中には、
目から鱗のような貴重な意見が含まれていたりします。

グレーな部分がありますが、
「前者は設計前」、「後者は設計後」という感じで、
両方できれば一番良いですが、
せめて片方だけでも徹底できればかなり結果が違うでしょう。

さて、DB設計者にとってお客様とは誰でしょう?
エンドユーザはもちろん、
そしてシステムを発注した会社ももちろんです。
もうちょい踏み込んでみましょう。

「インフラやアプリもお客様ではないでしょうか?」

この話の流れでの着目点は、
そう、DB設計者が作ったDB(テーブル)に対してSQL文を
実装していく「アプリの開発をするディベロッパー」です。
彼らが苦労するも楽(良いアプリに)するのも、
DB設計者の力量が大きく左右します。

「お客様の目線になりきる」を思い出して下さい。
「アプリの開発をするディベロッパー」
になりきってDB設計をすること「も」大事です。

でもそれは色々な都合で難しいこともあるかもって話をしました。
では、もう一つお客様の目線を得る方法がありましたよね?
そう「フィードバック」です。

アプリからのDBフィードバック

「アプリの開発をするディベロッパー」からのフィードバックは、
それこそ全ての要望を満たすことはできないと思いますが、
中にはとてもとても貴重な要素含まれていたりします。

「もの作りをする人間(DB設計者)としては、
これを得ずに設計を完了させるというのはあまりにもったいない」

と感じるわけです。

実務的なシステム開発全体の利益もそうですが、
なんというか...後世まで
「あの人(会社)の作ったDBはすげー実装しづらいね」
って、言われ続けるのはとてもいやじゃないですか?
(DBはとても長生きですからね)

もし、お客様という表現に違和感あるなら、
ステークホルダー(利害関係者)と置き換えましょう。
もったいないという話の構造には変わりはないので、
呼び名はどちらでもいいです。

当然、逆にパターンもありますが、
ここでは経験上多かったパターンを取り上げています。
なのでもちろん...

アプリ寄りなDB設計者もインフラ困らせないように頑張らないと!

#
# 自分がDB設計者のとき、
# 多くのディベロッパーから素敵なフィードバックを頂きました。
# もちろん全てを反映することはできないのですが、
# とても貴重でありがたいものでした。
#
# そういうことからも、
# やはり「開発中にDB変更がしやすいO/Rマッパ」というのは、
# DB設計者はとてもありがたいもので、
# 「DB設計者のためのツール」とも言えるでしょう。
#