2/4-5のリアクティブな話

pokarim @pokarim

RDBMSが中心となるようなシステム開発では、そうでない場合と比べて、アプリ側を手続き型言語から関数型言語に変えても、RDBモデルがボトルネックとなって全体の開発効率の改善が限定的になってしまうと考えてる。

pokarim @pokarim

Webアプリで後ろにDBMSがある場合、ひとつのレスポンスの為に必要なクエリが一発で済むなら、HTTPリクエストからクエリー、その結果からHTTPレスポンスの相互変換で済んでわりと関数的に書けると思うけど、実際はクエリ一発で済む事は少ない。

pokarim @pokarim

クエリ一発で済まないと何がまずいか。クエリの結果を元に別のクエリを出す必要があると、そこの制御はどうしても副作用を含むことになる。

pokarim @pokarim

ちょっとくらい副作用があってもかまわないけど、クエリ結果をもとに別のクエリといった形で副作用を含む制御が中心になるようなプログラムだと、関数型であることの利点は相対的に減る。型安全性云々は置いておくとして。

pokarim @pokarim

関数型にしても無駄と言いたい訳でなく、WebアプリでRDBMS中心のアプリの開発効率を抜本的に改善するためには、DBMS側のモデルの置き換えこそが必要なのではないかということ。宣言的なひとつのクエリでより多くの処理をこなせればたぶん色々嬉しい。

非実在naka aki @naka_aki_spl

@pokarim もしかしてRDB（のデータの持ち方）もしょせんはデザインパターンでしかないのかな。。。

pokarim @pokarim

@naka_aki_spl そうだと思います。RDBモデルしかちゃんとしたDBモデルが無いのは、いまたまたまそうなだけだと思います。

pokarim @pokarim

あと現状のRDBMS中心のWebアプリ開発でいまいちだと思うのは、制約条件のチェックをアプリ側でしたりDBMS側でしたり、ダブルチェックしたりしているところ。明らかにDRY原則やOnce And Only Once原則に反しているけど、あまり問題視されていない気がする。

marble @marblejenka

@pokarim 問題視されてないってのは、多分そんなことないと思います。クライアント側とサーバー側でロジックが二重持ちになってるのは忌避すべきと思われているかと。web屋さんで聞いた訳ではないですが、感覚は近いかと。

pokarim @pokarim

@marblejenka そうでしたか。ありがとうございます。現状はアプリ側中心でやってDBMS側は保険、みたいなパターンがやはり多いのでしょうか。

marble @marblejenka

@pokarim 僕の経験的にはあまりDBには頼っていなかったです。画面でのチェックはなるべく即時でユーザーにエラーを返すため、サーバーでのチェックはjs無効化されているケースに対応するため、という位置づけでした。コミットするタイミングでの間違いは結局アプリの間違という。。

marble @marblejenka

@pokarim さっきのは微妙に外していた感ですが、アプリでオブジェクトの関連的な制約を付け、DBに制約はつけない方針でした。なんともですが、アプリの実現手段にDBの設計があるものと考えると、そうなると。画面もアプリであるので、考慮の外かというとそうでもないですが。

pokarim @pokarim

@marblejenka 了解です。僕の感覚もほぼ同じです。問題視されていない云々は、ちょっと切り口が間違った気がしてきましたので仕切り直します。

pokarim @pokarim

@marblejenka 了解です。サーバ、クライアントの関係がSQLのとことHTTPのとこの両方にありますもんね。どっちにせよ通常DBMS側で複雑な業務ロジックのルールチェックはしませんもんね。

pokarim @pokarim

ロジックの２重持ちが問題視されてないことはないというツッコミをいただき、もちろんその通りなのでもう一度整理しなおす。

pokarim @pokarim

現実的にはDBMS側で宣言的に書ける制約条件は限られているので、業務ロジック的なチェックはアプリ中心に書く事になる。そこで嫌なのが、制約に違反するかどうかを調べるためにクエリーを投げる必要がある場合。このパターンはもちろんのこと結構多い。

pokarim @pokarim

なにが嫌かって制約条件のチェックなんて一番宣言的に書きたいようなところなのに、そこでクエリーが必要になるとどうしても手続き的になってしまう。もちろんDSL的なものを用意して見た目宣言的に書けるようにする事はできるけど、それも下手すると場当たり的になりがち。

pokarim @pokarim

全体をできるかぎり宣言的に書くには、業務ロジックやそのチェックもDBMS側で宣言的に記述できるようにするしかないと思う。その理由をちゃんと説明できた気はしないけど結論としてはそう思う。

pokarim @pokarim

MVCなど持ち出さなくても、本質的なロジックほど中心部分に記述した方が良いというのは感覚的にも当然なんだけど、一番の中心部分であるDBMS部分には書けずに一歩手前で汎用言語で記述するもんだからどうしてもそこが手続き的になってしまう。それをなんとかしたい。

marble @marblejenka

DBMSってアプリの中心かな？アプリはアプリであるけど機能的に(R)DBMSに依存してるだけだと思うけど。DBの制約（not null/foregin keyとか？）はなきゃないで別に死なないし。エンティティのライフサイクルをアプリできっちり管理できてれば問題ないかと。

marble @marblejenka

DB的にどうしようもないというか、暗黙的に依存してたのはtxだと思うけど、そこ意外で頼ってたかというと、別にって感じもする。逆説的な説明だけど、だからKVSとかクラウドとかに説得力も感じる。

Mamoru Iwasaki @mamoru125

@marblejenka ロジックをアプリとおっしゃるならDBじゃないかもですね。制約はデータのルールなのでアプリでも良いですが、複数アプリが無法にアクセスするとなるとDBのが都合良いです。全体像とバランスですかね。

marble @marblejenka

@mamoru125 なるほど。複数アプリで一つのDBを使うケースは見たことがないので、先の発言でした。そういう観点だとおっしゃる通りかと思います。

pokarim @pokarim

たしかにロジック中心にDBMSが中心でないとも言えます。その方向から考えれば、実際にデータを永続化する場所が外にあるのでアプリ側の記述がどうしても手続き的にならざるを得ないと言えると思います。 @marblejenka

pokarim @pokarim

もちろん永続化する場所が外にあってもそれだけで問題があるわけではない。繰り返しになるが単純にHTTPとSQLの１対１相互変換を行うだけで済むなら別に良い。１対１で済まないとどうやってもその部分が手続き的になってしまう。