データベースプログラミングに最適な言語は何か (335ﾚｽ)
上下前次1-新
15(1): 04/12/17 23:56 ID:??? AAS
>>13
データベースからの受け取り方で一番いいのは、
やはりハッシュ型なんだよ。キーを示して値を取る。
v = row['name']
または
v = row[:name]
これでいいじゃん。最も美しい。
わざわざオブジェクトにマッピングする意味は無いんだよ。
開発環境なんて、それの使い方覚える手間かかるじゃん。
スクリプト言語プラットフォームなら最低限、エディタがあればいい。
省3
16: 04/12/18 01:06 ID:??? AAS
.NETがその形式やね。
17: 04/12/18 01:11 ID:??? AAS
ﾍｼﾞﾀﾝ ﾊｧﾊｧ
18(2): 04/12/18 11:50 ID:IWYXFWeN(1) AAS
10 を書いたものです。>1 にしっかりした説明があるのに
間の抜けた事を書きました。じつは、データベースに最適な言語と
いう板の題目から、データベースの参照パターンのようなものが
ライブラリーにたくさん入っているというような言語を期待して
しまいました。
SQLの文字列が出てきたのでアレッと思ったのです。
SQLを書かなくて済むような言語はないのでしょうか。
19(2): 04/12/18 12:10 ID:??? AAS
>>18
SQLがダメだから、というのは、それはムリだよ。
RDBを扱う以上、SQLを書くことはどうしても必要で。
SQLを書き出すための文字列処理のプログラミングは必ずやることになる。
文字列処理が強力なプログラミング言語は何かなと考えるべきなんだよ。
そうすると、やはりRubyあたりがイイってことになってきちゃう。
XMLにおけるDOMのように、リレーショナルデータベースのリクエストをオブジェクトとして
構築する言語・プラットフォームを越えたAPIってのは、将来はありそうな気がするが
今でもそんなものは無いし、非現実的だ。
20(1): 04/12/18 12:15 ID:??? AAS
>>15
取ってきた値をちまちま代入するのがコードの無駄。
21(1): 04/12/18 12:22 ID:??? AAS
>>20
なんだよ。
データ取ってきてそれを一切どこにも代入しないってか。
22: 04/12/18 12:25 ID:??? AAS
>>19 にだ。
>SQLを書き出すための文字列処理のプログラミングは必ずやることになる。
>文字列処理が強力なプログラミング言語は何かなと考えるべきなんだよ。
DB云々ではなく、文字列処理をRubyで覚えたから使ってる orz.
23: 04/12/18 12:33 ID:??? AAS
>>19
SQL と文字列処理に強いかってのはあんまし関係ないと思うぞ。
>>18
RDB/SQL をデータの格納と取り出しだけの存在とみなすならいいのだけど、
実際には複数テーブルを join して集計したりと、
業務ロジックと密接な処理を SQL を用いて行う場面が多い。
そういった SQL/その RDB でできることをできる限りカバーしようと考えると、
プログラミング言語のライブラリ側に
SQL とほぼ一対一で変換できるようなオブジェクト
(Criteria オブジェクトとか良くあるけどさ) を導入することになる。
省3
24(3): 04/12/18 12:36 ID:??? AAS
s/はまだ/まだまだ
>>21
結局エンティティクラスのコンストラクタの引数に渡すか
作ったインスタンスにセッターメソッド使って値を代入することになるので、
それなら直接インスタンスになってくれた方がありがたい。
25: 04/12/18 12:38 ID:??? AAS
> SQL と文字列処理に強いかってのはあんまし関係ない
いや、自明のことというか、大ありだと思うんだが
Javaでやる文字列処理って、どんなにキレイに書こうとしても知れてるぞ。
26: 04/12/18 12:39 ID:??? AAS
>>24
なってるじゃん。Hashインスタンスに。
27(1): 04/12/18 12:42 ID:??? AAS
>>24
データベースから何か振る舞いを持つオブジェクトを作るって確かによくあること
だと思うが、それをプログラミングしないわけにはいかないだろ。
28: 04/12/18 12:46 ID:??? AAS
>>27
その部分をライブラリが勝手にやってくれてほしいってこと。
29: 04/12/18 12:49 ID:??? AAS
>>24
そういう「オブジェクトを作る」ってのは、データベースプログラミングの中でも
重要なトピックで、キャッシュが使えるところではキャッシュを使うとか、
ソフトウェア毎に最適な設計は異なるところで、その大切な部分を
自動化なんてできるわけないし、なんかのフレームワークとやらを使って
無理やりしようとしたころで適切なプログラミングよりシンプルに分かりやすく
なんてなりそうにない。
30(1): 04/12/18 12:54 ID:??? AAS
それは分るんだけどさ。
定型的だし書いていて何ら面白くないから、
フレームワークに追い出したいわけですよ。
31: 04/12/18 13:00 ID:??? AAS
>>30
定型的っていうけど、ホントかな。
適切なファクトリーメソッドの実装を見直して、モジュール化というか
プラグイン化を意識したコードにするとよいと思う。
アクセサメソッドが大量にあったりするとキモいね。
フレームワークは何の解決にもならないよ。
手続きがアプリケーション毎に違うからプログラミングするんだ。
32: 04/12/18 13:06 ID:??? AAS
適切に書かれたファクトリーメソッドがあると
そのシステムの意図がよく伝わると思うんだよね。
33(1): 04/12/18 13:21 ID:??? AAS
DB とプログラミング言語の界面はフレームワークに任せて、
その上の部分で 「手続き」 を実装したいんだよね。
なるべく疎な関係にしたい。
34: 04/12/18 13:28 ID:??? AAS
>>33
> プログラミング言語の界面はフレームワークに任せて
できるわけないし、やる意味ないと思うんだよ。
要求されている機能とデータベースの性質に合わせて
パフォーマンスのカ改善、キャッシュのヒット率を上げるとか
いろいろがんばらんといかんのに。
上下前次1-新書関写板覧索設栞歴
あと 301 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.068s