2011年2月5日

RDBMSとプログラミングパラダイム

RDBMSをデータの中心とした、手続き型・関数型・宣言的なリアクティブプログラミングの利用についての議論 ◆参考文献 なぜリアクティブプログラミングは重要か。 - Conceptual Contexture http://d.hatena.ne.jp/pokarim/20101226
20
pokarim @pokarim

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

2011-02-04 23:39:59
pokarim @pokarim

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

2011-02-04 23:56:38
pokarim @pokarim

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

2011-02-04 23:59:34
pokarim @pokarim

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

2011-02-05 00:14:58
pokarim @pokarim

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

2011-02-05 00:29:01
非実在naka aki @naka_aki_spl

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

2011-02-05 00:29:18
pokarim @pokarim

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

2011-02-05 00:31:41
pokarim @pokarim

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

2011-02-05 00:50:11
marble @marblejenka

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

2011-02-05 00:53:05
pokarim @pokarim

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

2011-02-05 00:54:35
marble @marblejenka

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

2011-02-05 00:58:42
pokarim @pokarim

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

2011-02-05 01:05:17
marble @marblejenka

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

2011-02-05 01:04:54
pokarim @pokarim

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

2011-02-05 01:10:20
pokarim @pokarim

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

2011-02-05 01:11:37
pokarim @pokarim

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

2011-02-05 01:15:21
pokarim @pokarim

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

2011-02-05 01:24:13
pokarim @pokarim

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

2011-02-05 01:26:40
pokarim @pokarim

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

2011-02-05 01:30:24
marble @marblejenka

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

2011-02-05 01:35:06
marble @marblejenka

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

2011-02-05 01:37:40
tagomoris @tagomoris

@marblejenka DBなんてぶっちゃけ複数のマシンにわたって多重化されたメモリ空間が無限にあったら絶対に使わないよね

2011-02-05 01:37:31
diskランドサガリベンジ @disktnk

@tagomoris @marblejenka 横から失礼します。そのメモリってのは、永続化できる、つまり電源切っても消えないメモリですか? であれば大いに同意です。

2011-02-05 01:40:18
残りを読む(86)

コメント

Masaki Yoshida @ReSTARTR 2011年2月5日
「RDBMSとプログラミングパラダイム」をトゥギャりました。 ※あとでデコレーションします。
0
Masaki Yoshida @ReSTARTR 2011年2月5日
「RDBMSとプログラミングパラダイム」に最新のツイートも追加しました。
0