アカウント名:
パスワード:
SQLデータベースをまるで単なるデータ置き場のように使うのって、OOP(しか知らない)連中が主に使っていたと思われるMySQLが5.0になるまでストプロはおろかビューすら実装されてない状態だったからじゃないですかね。 本来RDBMSを使う意味っていうのは、SQLを使って「何が欲しいか」だけ指定すれば、データ処理の詳細のロジックを作りこまなくてもオプティマイザがよしなにやってくれるので開発/実行効率がいいというところにあるわけで、オブジェクトをそのまま保存/取出しするなんていうことならそもそもSQLなんていう大オーバーヘッドを持っているRDBMSを使う意味がない。 でもOOPの連中はSQLプログラミングの手段としてのストプロとかビューというものを知らなかったから、その辺がピンと来てなかったんじゃないですかね。だからご苦労様なことにデータ操作のロジックをシコシコOOPで書いていた。というかMySQLにこだわるなら実際そうするしかなかったわけだし。 で、最近はMySQLでもそのあたりのサポートが充実してきたんで、ようやくそのことに気付いた人たちによる揺り戻しが来ていると。
社内独自実装のORMを使っていますが、大きな処理はストプロで出来るようにストプロをキックする仕組みは追加で実装されました。VIEWもロジックをDB側に任せる手段として使いますね。
要は、全部の処理をDBに任せないで・少量/逐次的なデータ処理→DB外・大量のデータ操作→DB内と切り分けることが大事だと経験的に感じています。
# BASICからアセンブラをちょこちょこ混ぜながら作る時の感覚ですかね
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
独断と偏見に基づいたORM史観 (スコア:2)
SQLデータベースをまるで単なるデータ置き場のように使うのって、OOP(しか知らない)連中が主に使っていたと思われるMySQLが5.0になるまでストプロはおろかビューすら実装されてない状態だったからじゃないですかね。
本来RDBMSを使う意味っていうのは、SQLを使って「何が欲しいか」だけ指定すれば、データ処理の詳細のロジックを作りこまなくてもオプティマイザがよしなにやってくれるので開発/実行効率がいいというところにあるわけで、オブジェクトをそのまま保存/取出しするなんていうことならそもそもSQLなんていう大オーバーヘッドを持っているRDBMSを使う意味がない。
でもOOPの連中はSQLプログラミングの手段としてのストプロとかビューというものを知らなかったから、その辺がピンと来てなかったんじゃないですかね。だからご苦労様なことにデータ操作のロジックをシコシコOOPで書いていた。というかMySQLにこだわるなら実際そうするしかなかったわけだし。
で、最近はMySQLでもそのあたりのサポートが充実してきたんで、ようやくそのことに気付いた人たちによる揺り戻しが来ていると。
Re:独断と偏見に基づいたORM史観 (スコア:0)
社内独自実装のORMを使っていますが、大きな処理はストプロで出来るように
ストプロをキックする仕組みは追加で実装されました。
VIEWもロジックをDB側に任せる手段として使いますね。
要は、全部の処理をDBに任せないで
・少量/逐次的なデータ処理→DB外
・大量のデータ操作→DB内
と切り分けることが大事だと経験的に感じています。
# BASICからアセンブラをちょこちょこ混ぜながら作る時の感覚ですかね