アカウント名:
パスワード:
SQLデータベースをまるで単なるデータ置き場のように使うのって、OOP(しか知らない)連中が主に使っていたと思われるMySQLが5.0になるまでストプロはおろかビューすら実装されてない状態だったからじゃないですかね。 本来RDBMSを使う意味っていうのは、SQLを使って「何が欲しいか」だけ指定すれば、データ処理の詳細のロジックを作りこまなくてもオプティマイザがよしなにやってくれるので開発/実行効率がいいというところにあるわけで、オブジェクトをそのまま保存/取出しするなんていうことならそもそもSQLなんていう大オーバーヘッドを持っているRDBMSを使う意味がない。 でもOOPの連中はSQLプログラミングの手段としてのストプロとかビューというものを知らなかったから、その辺がピンと来てなかったんじゃないですかね。だからご苦労様なことにデータ操作のロジックをシコシコOOPで書いていた。というかMySQLにこだわるなら実際そうするしかなかったわけだし。 で、最近はMySQLでもそのあたりのサポートが充実してきたんで、ようやくそのことに気付いた人たちによる揺り戻しが来ていると。
さすがに「ストアド?ビュー?あぁ、忘れてたわ」というレベルの強者はレアかと(笑)
すっげーSQLやらストアドやらを使うと確かに実装速度も動作速度も速いんですけど、
みたいなことが度々あって、面倒くさくなってテスト作成/実行しなくなっちゃうってことありません? 自分はこの流れでDBに複雑な処理を置かなくなりました。
楽したいのは山々なんだけど、
という方針をとっていると、DB内で複雑な処理をやらなくなるのは仕方の無いことなのかなーと思ったり。
> みたいなことが度々あって、面倒くさくなってテスト作成/実行しなくなっちゃうってことありません?> 自分はこの流れでDBに複雑な処理を置かなくなりました。
は?なんでこんなのが"参考になる"なんだよ
DBに処理任せないでも実行速度で困らない程度の実装しかしてないんでしょうか?幸せなんですね。
仕事でプログラム書かれてるなら、なんで商用RDBがあんな複雑な処理ができるのか少しは考えたほうがいいです。
みたいなことが度々あって、面倒くさくなってテスト作成/実行しなくなっちゃうってことありません? 自分はこの流れでDBに複雑な処理を置かなくなりました。DBに処理任せないでも実行速度で困らない程度の実装しかしてないんでしょうか?幸せなんですね。
話の流れを考えると「DBに処理を任せないと実行速度で困る」という問題領域を持ち出すのが適切なのか疑問が残ります。
そういうシビアな領域でORMが選択されるとは思えません。このストーリーの対象となる実装は、少なくともORMを適用することができる程度にはリソースに余裕があり、ORMを使わないという選択肢がパフォーマンス以外の理由で検討される場合のことだと思います。
そして、元のコメントは、そういう場合に、ORMを使えるけど使わないという選択をする理由としてそれなりに説得力があると思います。
なるほど。日本でこの手の議論をしてる人って商用DBか、OSSでもPostgreSQLを使ってる人が多くて、VIEWくらい常識という印象を受けたので、議論がかみ合わないわけですね。
煽った言い方をすると、あっちの人たちって低レベルな議論してるんですねと。
社内独自実装のORMを使っていますが、大きな処理はストプロで出来るようにストプロをキックする仕組みは追加で実装されました。VIEWもロジックをDB側に任せる手段として使いますね。
要は、全部の処理をDBに任せないで・少量/逐次的なデータ処理→DB外・大量のデータ操作→DB内と切り分けることが大事だと経験的に感じています。
# BASICからアセンブラをちょこちょこ混ぜながら作る時の感覚ですかね
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
独断と偏見に基づいたORM史観 (スコア:2)
SQLデータベースをまるで単なるデータ置き場のように使うのって、OOP(しか知らない)連中が主に使っていたと思われるMySQLが5.0になるまでストプロはおろかビューすら実装されてない状態だったからじゃないですかね。
本来RDBMSを使う意味っていうのは、SQLを使って「何が欲しいか」だけ指定すれば、データ処理の詳細のロジックを作りこまなくてもオプティマイザがよしなにやってくれるので開発/実行効率がいいというところにあるわけで、オブジェクトをそのまま保存/取出しするなんていうことならそもそもSQLなんていう大オーバーヘッドを持っているRDBMSを使う意味がない。
でもOOPの連中はSQLプログラミングの手段としてのストプロとかビューというものを知らなかったから、その辺がピンと来てなかったんじゃないですかね。だからご苦労様なことにデータ操作のロジックをシコシコOOPで書いていた。というかMySQLにこだわるなら実際そうするしかなかったわけだし。
で、最近はMySQLでもそのあたりのサポートが充実してきたんで、ようやくそのことに気付いた人たちによる揺り戻しが来ていると。
Re:独断と偏見に基づいたORM史観 (スコア:1, 参考になる)
さすがに「ストアド?ビュー?あぁ、忘れてたわ」というレベルの強者はレアかと(笑)
すっげーSQLやらストアドやらを使うと確かに実装速度も動作速度も速いんですけど、
みたいなことが度々あって、面倒くさくなってテスト作成/実行しなくなっちゃうってことありません?
自分はこの流れでDBに複雑な処理を置かなくなりました。
楽したいのは山々なんだけど、
という方針をとっていると、DB内で複雑な処理をやらなくなるのは仕方の無いことなのかなーと思ったり。
Re: (スコア:0)
> みたいなことが度々あって、面倒くさくなってテスト作成/実行しなくなっちゃうってことありません?
> 自分はこの流れでDBに複雑な処理を置かなくなりました。
は?なんでこんなのが"参考になる"なんだよ
DBに処理任せないでも実行速度で困らない程度の実装しかしてないんでしょうか?幸せなんですね。
仕事でプログラム書かれてるなら、なんで商用RDBがあんな複雑な処理ができるのか少しは考えたほうがいいです。
Re:独断と偏見に基づいたORM史観 (スコア:1)
話の流れを考えると「DBに処理を任せないと実行速度で困る」という問題領域を持ち出すのが適切なのか疑問が残ります。
そういうシビアな領域でORMが選択されるとは思えません。このストーリーの対象となる実装は、少なくともORMを適用することができる程度にはリソースに余裕があり、ORMを使わないという選択肢がパフォーマンス以外の理由で検討される場合のことだと思います。
そして、元のコメントは、そういう場合に、ORMを使えるけど使わないという選択をする理由としてそれなりに説得力があると思います。
LIVE-GON(リベゴン)
Re: (スコア:0)
Re: (スコア:0)
なるほど。日本でこの手の議論をしてる人って商用DBか、
OSSでもPostgreSQLを使ってる人が多くて、VIEWくらい常識という印象を受けたので、
議論がかみ合わないわけですね。
煽った言い方をすると、あっちの人たちって低レベルな議論してるんですねと。
Re: (スコア:0)
社内独自実装のORMを使っていますが、大きな処理はストプロで出来るように
ストプロをキックする仕組みは追加で実装されました。
VIEWもロジックをDB側に任せる手段として使いますね。
要は、全部の処理をDBに任せないで
・少量/逐次的なデータ処理→DB外
・大量のデータ操作→DB内
と切り分けることが大事だと経験的に感じています。
# BASICからアセンブラをちょこちょこ混ぜながら作る時の感覚ですかね