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