まず、漏れは Ruby を推したい。
内部イテレータのおかげで、短いコードでデータの取得、メモリの解放が可能だ。
Perl や PHP はオブジェクト指向の機能が不足である。Javaやは型宣言を
せねばならず、ムダにコードが長くなる。保守性は悪くなる。
つまり、Javaは別の分野で用いるべきである。
.NETやPythonは知らないが、.NETはJavaの片割れでたいしたメリット無いみたいだし、
PythonはRubyのライバルとされているが、どうか。イテレータの書きやすさは Ruby のほうがいいな。
データベース呼び出してるところのソースを載せていただけると
ありがたい。
http://ruby-dbi.sourceforge.net
C/C++じゃねーか？
データベース検索登録アプリケーションなら、PerlかJAVAあたりだが。
IDE使うのなら、Javaが一番メンテしやすいが。
ただ、他の言語に比べてどこがデータベース向きなのですか。
だね。
変数のやりとりを出来るところは便利だった。
といっても、PowerBuilder使ってた人なんて
ここにはまずいないだろうな・・・
require 'dbi'
DBI.connect('DBI:Mysql:test', 'testuser', 'testpwd') do | dbh |
puts "inserting..."
sql = "insert into simple01 (SongName, SongLength_s) VALUES (?, ?)"
dbh.prepare(sql) do | sth |
1.upto(13) { |i| sth.execute("Song #{i}", "#{i*10}") }
end
puts "selecting..."
dbh.select_all('select * from simple01') do | row |
p row
end
puts "deleting..."
dbh.do('delete from simple01 where internal_id > 10')
end
ブロックのおかげで処理のスコープが視覚的に分りやすいというのはあると思うが、
別段データベースに限ったことではないしな。
ライブラリの整備や開発環境のサポートを考えれば、
Class::DBI のある Perl や OR マッピングライブラリが盛んな Java の方が数歩先んでている。
データベースからの受け取り方で一番いいのは、
やはりハッシュ型なんだよ。キーを示して値を取る。
v = row['name']
または
v = row[:name]
これでいいじゃん。最も美しい。
わざわざオブジェクトにマッピングする意味は無いんだよ。
開発環境なんて、それの使い方覚える手間かかるじゃん。
スクリプト言語プラットフォームなら最低限、エディタがあればいい。
Javaは型宣言とかいろんな設定のために編集するもろもろのxmlファイル類を
ツールの手助け借りてやらないといけない。
本当は、実を取れば、こんな個別にツールの使い方覚えるまでもない。
間の抜けた事を書きました。じつは、データベースに最適な言語と
いう板の題目から、データベースの参照パターンのようなものが
ライブラリーにたくさん入っているというような言語を期待して
しまいました。
SQLの文字列が出てきたのでアレッと思ったのです。
SQLを書かなくて済むような言語はないのでしょうか。
SQLがダメだから、というのは、それはムリだよ。
RDBを扱う以上、SQLを書くことはどうしても必要で。
SQLを書き出すための文字列処理のプログラミングは必ずやることになる。
文字列処理が強力なプログラミング言語は何かなと考えるべきなんだよ。
そうすると、やはりRubyあたりがイイってことになってきちゃう。
XMLにおけるDOMのように、リレーショナルデータベースのリクエストをオブジェクトとして
構築する言語・プラットフォームを越えたAPIってのは、将来はありそうな気がするが
今でもそんなものは無いし、非現実的だ。
取ってきた値をちまちま代入するのがコードの無駄。
なんだよ。
データ取ってきてそれを一切どこにも代入しないってか。
>SQLを書き出すための文字列処理のプログラミングは必ずやることになる。
>文字列処理が強力なプログラミング言語は何かなと考えるべきなんだよ。
DB云々ではなく、文字列処理をRubyで覚えたから使ってる orz.
SQL と文字列処理に強いかってのはあんまし関係ないと思うぞ。
>>18
RDB/SQL をデータの格納と取り出しだけの存在とみなすならいいのだけど、
実際には複数テーブルを join して集計したりと、
業務ロジックと密接な処理を SQL を用いて行う場面が多い。
そういった SQL/その RDB でできることをできる限りカバーしようと考えると、
プログラミング言語のライブラリ側に
SQL とほぼ一対一で変換できるようなオブジェクト
(Criteria オブジェクトとか良くあるけどさ) を導入することになる。
が、OR マッピングのライブラリの仕様はまちまちだし、
はまだ SQL でできる範囲をカバーしきれていないので、
それなら SQL をそのまま使った方がいいというのが現状。
>>21
結局エンティティクラスのコンストラクタの引数に渡すか
作ったインスタンスにセッターメソッド使って値を代入することになるので、
それなら直接インスタンスになってくれた方がありがたい。
いや、自明のことというか、大ありだと思うんだが
Javaでやる文字列処理って、どんなにキレイに書こうとしても知れてるぞ。
なってるじゃん。Hashインスタンスに。
データベースから何か振る舞いを持つオブジェクトを作るって確かによくあること
だと思うが、それをプログラミングしないわけにはいかないだろ。
その部分をライブラリが勝手にやってくれてほしいってこと。
そういう「オブジェクトを作る」ってのは、データベースプログラミングの中でも
重要なトピックで、キャッシュが使えるところではキャッシュを使うとか、
ソフトウェア毎に最適な設計は異なるところで、その大切な部分を
自動化なんてできるわけないし、なんかのフレームワークとやらを使って
無理やりしようとしたころで適切なプログラミングよりシンプルに分かりやすく
なんてなりそうにない。
定型的だし書いていて何ら面白くないから、
フレームワークに追い出したいわけですよ。
定型的っていうけど、ホントかな。
適切なファクトリーメソッドの実装を見直して、モジュール化というか
プラグイン化を意識したコードにするとよいと思う。
アクセサメソッドが大量にあったりするとキモいね。
フレームワークは何の解決にもならないよ。
手続きがアプリケーション毎に違うからプログラミングするんだ。
そのシステムの意図がよく伝わると思うんだよね。
その上の部分で 「手続き」 を実装したいんだよね。
なるべく疎な関係にしたい。
> プログラミング言語の界面はフレームワークに任せて
できるわけないし、やる意味ないと思うんだよ。
要求されている機能とデータベースの性質に合わせて
パフォーマンスのカ改善、キャッシュのヒット率を上げるとか
いろいろがんばらんといかんのに。
そんなに必要無いってこともあるかもしれないけど。
しかし、データベースかオブジェクトを作るシーンってそんなに
多いかね。たとえば、社員の勤怠管理のシステム作るとして、
どれだけクラス書くかな、せいぜい６コくらいのクラスで
十分じゃないかしら。
今開発運用しているのが 30 位のクラスと同じくらいのテーブルを持ったウェブアプリで
隔月に一度は機能拡張している。
予想以上にユーザが増えたので、今は PostgreSQL なのを Oracle にしようという話もあったりして。
RDB 向きの使い方じゃないのかも。
拡張性を重視するだから、
どの言語を選んでどういう作り方をしているのか教えてくらはい
1.JDBC/ODBC/OLE-DBなどの結果セット型
2.SQL-JやPRO*Cなどの埋め込み型SQL
3.簡易言語などに見られるデータベースを直接操作する命令をもつ言語
4.ストアドプロシージャをベースに簡易言語に発展させたもの
5.O-Rマッピング
6.DBMS固有のAPI(CLI)を直接操作
1を前提にするならオブジェクトが扱いやすい言語が有利か。
パフォーマンスを重視するなら2もいいのだがなぜか人気がない。
3と4は環境依存なのが難点だがプログラム言語の型とデータベースの型が一致することが
多いので、適用分野を間違わなければ使いやすいかもしれない。
5はいまだ未知数で6はもう疲れた・・
Perl と Class:DBI ベースの DB 中間層と
CGI::Application ライクな独自のウェブアプリケーションフレームワーク。
O-Rマッピングだよね。
O-Rマッピングの意義を誰か教えてほしいよ。マジで。
振る舞いを持つ必要なんてほとんどないのに
（あったとしても、それはプログラミングすべきだ）、
なんでオブジェクトにするんだ。
なんかマッピングすることを目的にしちゃってて複雑化しすぎ。本末転倒だよ。
お前がオブジェクト指向で設計してないからだろ。
違うんだよ。使うところでしっかり使う。
しかし、たとえば、何かの住所録でもって
人のカラムを表現するのに Human クラスとかなんとか作って、
でもそれに何かメソッドを定義するかといえば、何も無いんだよ。
それでデータベースとオブジェクトとのマッピングとかいっても、お笑いなわけ。
必要な人がたくさんいるから、それができあがったわけで。
良さそうな香りはするんだが、現状では使ってみると幻滅することが多い。
「必要な人」でも現在のO-Rマッピングには不満を持ってる人は多いと思うよ。
なんでそんなことになるのさ〜♪
話をSQLだけに絞って、
SQLの完全なるParserを持つ必要はないのですか。逆に処理系が
SQLを「生成」するとなると必須とおもいますが。
なんで必要なのかしら
理由を教えてくれ
プログラマがSQL文字列を知っている必要があるクラスと
コンパイラがSQLを構成するクラスとありそうに思えたから。
ボクシングとK-1ほどに上がる舞台がちがうのではないか。
Parserが必要と感じるのはもちろん後のクラス。関数型言語で
SQL相当の操作を書くとすれば、文字列操作の云々は的外れ
となり、むしろSQL文字列にどう組み立てなおすかが課題となる。
そんな意味なのですが。
ドライバやクラスで吸収するには違いが大きすぎる。
すんません。
コンパイラがSQLを構成するっていうのが、私、あまり知らないのですが。
それは例えばどういうものか教えてくれますか？
>52 私も知りません。無責任で申し訳ない。
読み返してみるとParserとかコンパイラとかの用語選択も適切でなかった。それで仕切りなおし。
Lispでと思ったのですが括弧ばかりで上手く説明できそうにないのでProlog風に行きます。
select,into,from 等が適切にオペレータ定義されて、
(select * into X from Table) :- ...... (1)
のようにSQLのパターンが述語として定義されたとします。これをプログラムのなかで
?- ...... ,select * into X from emp, ...... のように使うことは利用者がSQLを知っている
ことを前提にしているという意味で "select * from emp" と文字列で処理するのと
変わりありません。次に、(1)のパターンばかりでなく、考えられる全てのSQLの参照(操作)パターンを
定義できたとします。その上で、
rdb_call('emp表の全ての組',X):- ......... (2)
を定義し、(2) :- の右側で、'emp表の全ての組'を解析して(1) を引き出すことができるとすれば、
この段階で、利用者はSQLを知る必要はなくなります。この例は引数がほとんど自然言語ですから、
相当に複雑になるでしょうが。
(2)のようなライブラリーを充実して、データベースに対処しようとすることはSQL文字列を生成したり
表記する方法を洗練することとはやはりステージが違うと考えるべきだということです。50で述べたかった
ことはそういうことです。(2)のようなライブラーだけでデータベース操作を行い得ないということも当然でしょう。
(2)を目指しながら、(1)のレベルを排除しないというのが現実的な処理系の対応になると思います。
それから、(1)のようなパターンを全て定義済みならば、*.sqlのようなファイルをそのまま実行することも
可能なはずです。Parserという言葉はその意味で使いました。
日本語がネイティブの人間と意思疎通を図るなら日本語が良いのと同じ。
その意味では RDB とオブジェクト指向言語の間の
インピーダンスミスマッチは原理的にすべて解消はできない。
そう思います。
しかし、RDBモデルが極めてシンプルな構造のモデルだから、SQLのような
論理式で済んでいる、ということはないのですか。優れて恵まれた状況だと。
グラフィックインターフェイスを必要とするようなモデルも視野に入れると、
>1 でRubyが推されたような前提が成立しないのではないか。
現実ではやはりSQLというものが使われてしまっているのよね。
ちなみに、リレーショナルデータベース使うまでもないシーンでも、
RubyにはDBMが簡単に扱えるライブラリが標準で付いてる。
ＰｏｗｅｒＢｕｉｌｄｅｒもＶＢも使ってたよ。
ＰｏｗｅｒＢｕｉｌｄｅｒはＣ／Ｓ系システム向けだね。
ＶＢ知ってれば非常に作りやすいし、ＶＢ／ＶＣと違ってocxとか考えなくて良いから楽ちん。
いかんせん メジャーじゃないし 高杉だ。
VisualStadio.net(MSDN)より高いってどういうことよ？（ｗ
ウィンドウヴィジットによるユーザインターフェースが絡むとなると、
ますます、オブジェクト指向の機能が欲しくなるんじゃなかろうか。
まぁ、Javaもそんなに悪い選択肢だとは思ってないよ。
Javaはウェブプログラミングには向いてないとは思うけどね。
データベースのプログラミングやるなら、
スクリプト言語で組んだほうがどちらにしても効率いいな。
より生産性が高いから(ということにしたいのだろう)
あと、MSDNは薄利多売だからな
そこがJavaの欠点と言える。
豪勢なIDEが無いとまともに編集できないのはどうか。
それよりは、エディタ一つあればできるものであるほうがいい。
別にソース一本で終わるように作れば、JAVAだって可能だが。
Servletに全部ロジックも表示もべた書きすればいいわけだし。
PerlやPHPはそれをやってるから一本で終わってるだけで、
MVC分割だの、よく使うロジックはわけるだのやってたら、
ソースの本数は増えて、JAVAが普通に複数ソースに
なるようなのと同じになるわけだが。
結局、言語云々ではなく、作り方云々だろ。ソースがどうなるかなんて。
そーすね
いや、どんなに単純化しようとも、JavaにはIDEは必須。間違いない。
作り方云々なのは、それはそうなんだ。当たり前の話。
いい作り方って eXtreme Programming で十分示されているから、
それをうまくやる最適な言語は何かと考えるわけだな。
ソースと掛けてるのか？( ´,_ゝ｀)ﾌﾟｯ
> 64 名前：NAME IS NULL[] 投稿日：05/01/01 21:26:46 ID:DTmypz3j
> >>62
> ソースと掛けてるのか？( ´,_ゝ｀)ﾌﾟｯ
お客様にお願いいたします。
釣りもしくは自演をなさるのならせめて ID を変えていただけませんか ?
必須じゃないよ。
ソースが1本か2本な人もいるかもしれないのに、JAVAだからと言う理由で
IDE使わなければならないと力説するのは無意味だろう。
んなアフォな
ｵﾚﾓ悩んだ ちゃんと金払ったら治ったYp!
コンパイラであっても同能力のインタプリタが動かないと
その資格がないのではないか。
パワースペースとオンラインヘルプ
SQLとXBASE以外に知らんからマニアックな話題が飛び交ってるものかと・・・。
ＶＢ
ＷＥＢで簡単に作る
ＰＨＰ
ってのは無しですか。
OS/400x86版をオープンソースで出してくれたらいいのにな。
SQL="SELECT"
SQL=SQL+"ID, NAME"
・・・
うざっ！
SQL言語とか
昔のSQL*ReportやSQL*Formがそんな言語を使ってました。
もっともあれはあれで うざっ！かったような記憶があります。
最近のJDeveloperはどうな感じなのだろう。
LISP,Prologといった記号処理言語が一番ですね。
荒川は英語で、ARAKAWA RIVERなわけだが何か？
http://www.ara.or.jp/e/e_index.html
知ってるが、それが何か関係ある？
>>92
何でそう莫迦なの？
2. 「SQL を、整形せずに埋め込める言語は？」の問いに
「SQL」と答える間抜けさ。
3. SQL はプログラミング言語ではない。
取り敢えず >>84 は PL/SQL (サーバサイド) ないし
Pro*C (も言語じゃないが。クライアントサイド) でも使えと。
ただし、Turing Completeではないだけ。
でも言語の選択よりもバインディングがしやすいかどうかのほうが重要な気がする。
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
データベースなんか作れるかよ！ (165)
データベース系の仕事をしたくて探しているのですが (157)
さて、この板の看板だが (142)
データベース雑誌・書籍 (182)
CSVファイルのスレ (219)
彼女にINSERT権限がありません (816)
--log9.info------------------
東京幻想はトレースだという話がでているが。 (877)
ネームを切る！ (531)
「新刊献上・交換・頂戴」モニョる時／18冊目 (254)
一人で外注を使わず同人ゲームを作る輩が集うスレ4 (169)
てーへん ◆/dFe/L4S/k (275)
モチベ維持スレ4 (924)
同人の距離梨について語る3 (582)
鰯最下層から万年浪人で墓場まで5 (677)
千葉県船橋市の同人事情２ (935)
吐き気がする程嫌いなキャラ2 (463)
同人ゲームを作る輩が集うスレ7 (730)
小説・文章の評価をするスレ Part13【本人限定】 (152)
絵初心者である営業マン達の成長過程を見るスレ (136)
なりきり被害全般スレ28 (304)
古参に愚痴るスレ (393)
【中の人】同人系印刷所従事者スレ その6【専用】 (203)
--log55.com------------------
なぜ自民党は犯罪者安倍晋三を降ろさないのか
安倍首相「誰もが正社員になれる時代が来ました」
日本を守る公安調査庁
真の中道保守政党をつくれ 維新自公は売国奴
橋下徹が自Rるまでage続けるスレ
橋下徹はもうダメ…Part１９
【森友文書】リスクの高い書き換えを公務員がやる？
☆アベノミクス・１億総活躍で政策議論（１８）