データベースプログラミングに最適な言語は何か

1 ：04/12/17 〜 最終レス ：11/06/09

データベースプログラミングに最適な言語は何かを論じたい。
まず、漏れは Ruby を推したい。
内部イテレータのおかげで、短いコードでデータの取得、メモリの解放が可能だ。
Perl や PHP はオブジェクト指向の機能が不足である。Javaやは型宣言を
せねばならず、ムダにコードが長くなる。保守性は悪くなる。
つまり、Javaは別の分野で用いるべきである。
.NETやPythonは知らないが、.NETはJavaの片割れでたいしたメリット無いみたいだし、
PythonはRubyのライバルとされているが、どうか。イテレータの書きやすさは Ruby のほうがいいな。

2 ：

ＲＵＢＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹ！！！！！！

3 ：

Ruby知りません。
データベース呼び出してるところのソースを載せていただけると
ありがたい。

4 ：

>>3
http://ruby-dbi.sourceforge.net

5 ：

データベースプログラミング？
C/C++じゃねーか？
データベース検索登録アプリケーションなら、PerlかJAVAあたりだが。

6 ：

>>1はJavaのコードをテキストエディタかなんかで保守してるのか？
IDE使うのなら、Javaが一番メンテしやすいが。

7 ：

T-SQLとかPL/SQLじゃだめ？

8 ：

PL/SQLでクライアント作れるならいいんじゃねーの？

9 ：

VBだろ

10 ：

>4 ありがとうございます。なんとなくわかりました。
ただ、他の言語に比べてどこがデータベース向きなのですか。

11 ：

>>9
だね。

12 ：

PowrBuilderの、ソース内にそのままSQLを書いて
変数のやりとりを出来るところは便利だった。
といっても、PowerBuilder使ってた人なんて
ここにはまずいないだろうな・・・

13 ：

4 のサイトのコードをコピペしてみる。
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 の方が数歩先んでている。

14 ：

Developer2000使ってPL/SQLと怪しげなパッケージ(組み込み関数)でプログラム作ったっけ・・・。

15 ：

>>13
データベースからの受け取り方で一番いいのは、
やはりハッシュ型なんだよ。キーを示して値を取る。
v = row['name']
または
v = row[:name]
これでいいじゃん。最も美しい。
わざわざオブジェクトにマッピングする意味は無いんだよ。
開発環境なんて、それの使い方覚える手間かかるじゃん。
スクリプト言語プラットフォームなら最低限、エディタがあればいい。
Javaは型宣言とかいろんな設定のために編集するもろもろのxmlファイル類を
ツールの手助け借りてやらないといけない。
本当は、実を取れば、こんな個別にツールの使い方覚えるまでもない。

16 ：

.NETがその形式やね。

17 ：

ﾍｼﾞﾀﾝ ﾊｧﾊｧ

18 ：

10 を書いたものです。>1　にしっかりした説明があるのに
間の抜けた事を書きました。じつは、データベースに最適な言語と
いう板の題目から、データベースの参照パターンのようなものが
ライブラリーにたくさん入っているというような言語を期待して
しまいました。
SQLの文字列が出てきたのでアレッと思ったのです。
SQLを書かなくて済むような言語はないのでしょうか。

19 ：

>>18
SQLがダメだから、というのは、それはムリだよ。
RDBを扱う以上、SQLを書くことはどうしても必要で。
SQLを書き出すための文字列処理のプログラミングは必ずやることになる。
文字列処理が強力なプログラミング言語は何かなと考えるべきなんだよ。
そうすると、やはりRubyあたりがイイってことになってきちゃう。
XMLにおけるDOMのように、リレーショナルデータベースのリクエストをオブジェクトとして
構築する言語・プラットフォームを越えたAPIってのは、将来はありそうな気がするが
今でもそんなものは無いし、非現実的だ。

20 ：

>>15
取ってきた値をちまちま代入するのがコードの無駄。

21 ：

>>20
なんだよ。
データ取ってきてそれを一切どこにも代入しないってか。

22 ：

>>19　にだ。
>SQLを書き出すための文字列処理のプログラミングは必ずやることになる。
>文字列処理が強力なプログラミング言語は何かなと考えるべきなんだよ。
DB云々ではなく、文字列処理をRubyで覚えたから使ってる orz.

23 ：

>>19
SQL と文字列処理に強いかってのはあんまし関係ないと思うぞ。
>>18
RDB/SQL をデータの格納と取り出しだけの存在とみなすならいいのだけど、
実際には複数テーブルを join して集計したりと、
業務ロジックと密接な処理を SQL を用いて行う場面が多い。
そういった SQL/その RDB でできることをできる限りカバーしようと考えると、
プログラミング言語のライブラリ側に
SQL とほぼ一対一で変換できるようなオブジェクト
(Criteria オブジェクトとか良くあるけどさ) を導入することになる。
が、OR マッピングのライブラリの仕様はまちまちだし、
はまだ SQL でできる範囲をカバーしきれていないので、
それなら SQL をそのまま使った方がいいというのが現状。

24 ：

s/はまだ/まだまだ
>>21
結局エンティティクラスのコンストラクタの引数に渡すか
作ったインスタンスにセッターメソッド使って値を代入することになるので、
それなら直接インスタンスになってくれた方がありがたい。

25 ：

> SQL と文字列処理に強いかってのはあんまし関係ない
いや、自明のことというか、大ありだと思うんだが
Javaでやる文字列処理って、どんなにキレイに書こうとしても知れてるぞ。

26 ：

>>24
なってるじゃん。Hashインスタンスに。

27 ：

>>24
データベースから何か振る舞いを持つオブジェクトを作るって確かによくあること
だと思うが、それをプログラミングしないわけにはいかないだろ。

28 ：

>>27
その部分をライブラリが勝手にやってくれてほしいってこと。

29 ：

>>24
そういう「オブジェクトを作る」ってのは、データベースプログラミングの中でも
重要なトピックで、キャッシュが使えるところではキャッシュを使うとか、
ソフトウェア毎に最適な設計は異なるところで、その大切な部分を
自動化なんてできるわけないし、なんかのフレームワークとやらを使って
無理やりしようとしたころで適切なプログラミングよりシンプルに分かりやすく
なんてなりそうにない。

30 ：

それは分るんだけどさ。
定型的だし書いていて何ら面白くないから、
フレームワークに追い出したいわけですよ。

31 ：

>>30
定型的っていうけど、ホントかな。
適切なファクトリーメソッドの実装を見直して、モジュール化というか
プラグイン化を意識したコードにするとよいと思う。
アクセサメソッドが大量にあったりするとキモいね。
フレームワークは何の解決にもならないよ。
手続きがアプリケーション毎に違うからプログラミングするんだ。

32 ：

適切に書かれたファクトリーメソッドがあると
そのシステムの意図がよく伝わると思うんだよね。

33 ：

DB とプログラミング言語の界面はフレームワークに任せて、
その上の部分で 「手続き」 を実装したいんだよね。
なるべく疎な関係にしたい。

34 ：

>>33
> プログラミング言語の界面はフレームワークに任せて
できるわけないし、やる意味ないと思うんだよ。
要求されている機能とデータベースの性質に合わせて
パフォーマンスのカ改善、キャッシュのヒット率を上げるとか
いろいろがんばらんといかんのに。

35 ：

まぁ、タイトなパフォーマンスが要求されるかどうかは、
そんなに必要無いってこともあるかもしれないけど。
しかし、データベースかオブジェクトを作るシーンってそんなに
多いかね。たとえば、社員の勤怠管理のシステム作るとして、
どれだけクラス書くかな、せいぜい６コくらいのクラスで
十分じゃないかしら。

36 ：

パフォーマンスより拡張性重視で使っているからなあ。
今開発運用しているのが 30 位のクラスと同じくらいのテーブルを持ったウェブアプリで
隔月に一度は機能拡張している。
予想以上にユーザが増えたので、今は PostgreSQL なのを Oracle にしようという話もあったりして。
RDB 向きの使い方じゃないのかも。

37 ：

>>36
拡張性を重視するだから、
どの言語を選んでどういう作り方をしているのか教えてくらはい

38 ：

データベースを操作する場合の思いつく手法をあげてみるとこんな感じなのだが、
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はもう疲れた・・

39 ：

>>37
Perl と Class:DBI ベースの DB 中間層と
CGI::Application ライクな独自のウェブアプリケーションフレームワーク。

40 ：

S2DAOあたりではダメかな

41 ：

Class::DBI も S2DAO
O-Rマッピングだよね。
O-Rマッピングの意義を誰か教えてほしいよ。マジで。
振る舞いを持つ必要なんてほとんどないのに
（あったとしても、それはプログラミングすべきだ）、
なんでオブジェクトにするんだ。
なんかマッピングすることを目的にしちゃってて複雑化しすぎ。本末転倒だよ。

42 ：

>>41
お前がオブジェクト指向で設計してないからだろ。

43 ：

>>42
違うんだよ。使うところでしっかり使う。
しかし、たとえば、何かの住所録でもって
人のカラムを表現するのに Human クラスとかなんとか作って、
でもそれに何かメソッドを定義するかといえば、何も無いんだよ。
それでデータベースとオブジェクトとのマッピングとかいっても、お笑いなわけ。

44 ：

だから、必要ないなら使わなきゃいいじゃん。
必要な人がたくさんいるから、それができあがったわけで。

45 ：

O-Rマッピングは「できあがって」はいないと思うな。まだ発展途上だ。
良さそうな香りはするんだが、現状では使ってみると幻滅することが多い。
「必要な人」でも現在のO-Rマッピングには不満を持ってる人は多いと思うよ。

46 ：

フロントエンドはAccess以外に考えられない

47 ：

そんなことより「ID:???」が気になる・・
なんでそんなことになるのさ〜♪

48 ：

>38-46 (最)適性の要件について
話をSQLだけに絞って、
SQLの完全なるParserを持つ必要はないのですか。逆に処理系が
SQLを「生成」するとなると必須とおもいますが。

49 ：

>>48
なんで必要なのかしら
理由を教えてくれ

50 ：

>49 一連の議論を読んでいると、同じ「最適な言語」を競っても
プログラマがSQL文字列を知っている必要があるクラスと
コンパイラがSQLを構成するクラスとありそうに思えたから。
ボクシングとK-1ほどに上がる舞台がちがうのではないか。
Parserが必要と感じるのはもちろん後のクラス。関数型言語で
SQL相当の操作を書くとすれば、文字列操作の云々は的外れ
となり、むしろSQL文字列にどう組み立てなおすかが課題となる。
そんな意味なのですが。

51 ：

データベース側が統一が取れてないからそっちを何とかしないとなぁ。
ドライバやクラスで吸収するには違いが大きすぎる。

52 ：

>>50
すんません。
コンパイラがSQLを構成するっていうのが、私、あまり知らないのですが。
それは例えばどういうものか教えてくれますか？

53 ：

4,10,18,48,50 と書き込みできた者です。
>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という言葉はその意味で使いました。

54 ：

SQL と構文レベル、意味レベルにおいて等価であるなら、SQL そのものを使えばいい。
日本語がネイティブの人間と意思疎通を図るなら日本語が良いのと同じ。
その意味では RDB とオブジェクト指向言語の間の
インピーダンスミスマッチは原理的にすべて解消はできない。

55 ：

> SQL と構文レベル、意味レベルにおいて等価であるなら、SQL そのものを使えばいい。
そう思います。
しかし、RDBモデルが極めてシンプルな構造のモデルだから、SQLのような
論理式で済んでいる、ということはないのですか。優れて恵まれた状況だと。
グラフィックインターフェイスを必要とするようなモデルも視野に入れると、
>1 でRubyが推されたような前提が成立しないのではないか。

56 ：

>>55
現実ではやはりSQLというものが使われてしまっているのよね。
ちなみに、リレーショナルデータベース使うまでもないシーンでも、
RubyにはDBMが簡単に扱えるライブラリが標準で付いてる。

57 ：

>>12
ＰｏｗｅｒＢｕｉｌｄｅｒもＶＢも使ってたよ。
ＰｏｗｅｒＢｕｉｌｄｅｒはＣ／Ｓ系システム向けだね。
ＶＢ知ってれば非常に作りやすいし、ＶＢ／ＶＣと違ってocxとか考えなくて良いから楽ちん。
いかんせん メジャーじゃないし 高杉だ。
VisualStadio.net(MSDN)より高いってどういうことよ？（ｗ

58 ：

ウェブインターフェースでもそうだが
ウィンドウヴィジットによるユーザインターフェースが絡むとなると、
ますます、オブジェクト指向の機能が欲しくなるんじゃなかろうか。
まぁ、Javaもそんなに悪い選択肢だとは思ってないよ。
Javaはウェブプログラミングには向いてないとは思うけどね。
データベースのプログラミングやるなら、
スクリプト言語で組んだほうがどちらにしても効率いいな。

59 ：

>>57
より生産性が高いから(ということにしたいのだろう)
あと、MSDNは薄利多売だからな

60 ：

>>6
そこがJavaの欠点と言える。
豪勢なIDEが無いとまともに編集できないのはどうか。
それよりは、エディタ一つあればできるものであるほうがいい。

61 ：

>>60
別にソース一本で終わるように作れば、JAVAだって可能だが。
Servletに全部ロジックも表示もべた書きすればいいわけだし。
PerlやPHPはそれをやってるから一本で終わってるだけで、
MVC分割だの、よく使うロジックはわけるだのやってたら、
ソースの本数は増えて、JAVAが普通に複数ソースに
なるようなのと同じになるわけだが。
結局、言語云々ではなく、作り方云々だろ。ソースがどうなるかなんて。

62 ：

>>61
そーすね

63 ：

>>61
いや、どんなに単純化しようとも、JavaにはIDEは必須。間違いない。
作り方云々なのは、それはそうなんだ。当たり前の話。
いい作り方って eXtreme Programming で十分示されているから、
それをうまくやる最適な言語は何かと考えるわけだな。

64 ：

>>62
ソースと掛けてるのか？( ´,_ゝ｀)ﾌﾟｯ

65 ：

> 62 名前：NAME IS NULL[] 投稿日：05/01/01 09:12:20 ID:DTmypz3j
> 64 名前：NAME IS NULL[] 投稿日：05/01/01 21:26:46 ID:DTmypz3j
> >>62
> ソースと掛けてるのか？( ´,_ゝ｀)ﾌﾟｯ
お客様にお願いいたします。
釣りもしくは自演をなさるのならせめて ID を変えていただけませんか ?

66 ：

>>63
必須じゃないよ。

67 ：

SCSIのほうがよかんべよ

68 ：

>>63
ソースが1本か2本な人もいるかもしれないのに、JAVAだからと言う理由で
IDE使わなければならないと力説するのは無意味だろう。

69 ：

>>68
んなアフォな

70 ：

teratermで日本語打とうすると「ピッ！」とかいってキャンセルされるんだけどなんで？

71 ：

>>70
ｵﾚﾓ悩んだ　ちゃんと金払ったら治ったYp!

72 ：

cobol

73 ：

考えてみると、「最適な」というからには、
コンパイラであっても同能力のインタプリタが動かないと
その資格がないのではないか。

74 ：

ＰｏｗｅｒＢｕｉｌｄｅｒ勉強したいのですが、なにか参考になるサイトがあれば教えてください

75 ：

>>74
パワースペースとオンラインヘルプ

76 ：

やっぱＨＴＭＬだろ

77 ：

やっぱＯＴＬだろ

78 ：

なんだ、このスレＤＢの問い合わせ言語比較スレかと思ったら違うのか。
SQLとXBASE以外に知らんからマニアックな話題が飛び交ってるものかと・・・。

79 ：

むしろTCP/IPだろ

80 ：

Ｃ／Ｓで簡単に作る
ＶＢ
ＷＥＢで簡単に作る
ＰＨＰ

81 ：

Delphiも仲間に入れて

82 ：

ILE RPG
ってのは無しですか。

83 ：

>>82
OS/400x86版をオープンソースで出してくれたらいいのにな。

84 ：

SQL*Plusなんかで動作確認したSQLを、そのままカッペして動く言語はないでしか？
SQL="SELECT"
SQL=SQL+"ID, NAME"
・・・
うざっ！

85 ：

>>84
SQL言語とか

86 ：

>>84
昔のSQL*ReportやSQL*Formがそんな言語を使ってました。
もっともあれはあれで うざっ！かったような記憶があります。
最近のJDeveloperはどうな感じなのだろう。

87 ：

(´-`).｡ｏＯ（SQL言語？）

88 ：

PSQL や　SQL+　クラスのインタプリタを自ら書く(言語を創る)なら、
LISP,Prologといった記号処理言語が一番ですね。

89 ：

>>87
荒川は英語で、ARAKAWA RIVERなわけだが何か？
http://www.ara.or.jp/e/e_index.html

90 ：

C#が真打ち

91 ：

硫黄島は英語で Iwojima Island なのだ

92 ：

87は当然厳密に、ＳＱ言語とか言うのか？

93 ：

>>89
知ってるが、それが何か関係ある？
>>92
何でそう莫迦なの？

94 ：

>>87は、SQL言語の何処に食いついたのか説明すべきだろう

95 ：

1. L は Language。
2. 「SQL を、整形せずに埋め込める言語は？」の問いに
　　「SQL」と答える間抜けさ。
3. SQL はプログラミング言語ではない。
取り敢えず >>84 は PL/SQL (サーバサイド) ないし
Pro*C (も言語じゃないが。クライアントサイド) でも使えと。

96 ：

SQLはプログラミング言語の一つだと思うが、なんでそこまで断言できるのか不思議。

97 ：

SQLは当然、プログラミング言語。
ただし、Turing Completeではないだけ。

98 ：

まじBasicに統一してほしい。まじで

99 ：

C# か Java がやっぱり委員で内科医？
でも言語の選択よりもバインディングがしやすいかどうかのほうが重要な気がする。

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

SQLite 9 (872)
【無料DB】OpenOffice2.0?Base【Accessｲﾗﾈ】 (593)
OODB - オブジェクト指向データベース (296)
SQLite 9 (872)
数十メガバイトのファイルをどんどん格納できるDB (202)
MySQL vs PostgreSQL Part2 (676)
--log9.info------------------
イタレリ尽くせり（核爆） (566)
●●模型レオナルド●● (894)
↑と↓のスレタイを合体させるスレin模型・プラモ板 (237)
★模型塗装スレッド64 ｶﾞﾝﾌﾟﾗからｽｹｰﾙまで★ (772)
山梨の模型事情　その5 (628)
ガンプラ特売情報本スレ全国編Part.60 (634)
個人店の接客態度は異常 (259)
「アトリエ彩」の店舗閉店 (807)
♪バス模型スレッドPart16 (523)
コピー疑惑 【代アニ　工房ときたま　飯田実】 2 (580)
【BANDAI】マクロス関連スレVF-30【専用】 (633)
筆塗り総合スレッド7 (575)
下手糞の下手糞による下手糞の為のスレッド　その２ (393)
【北欧】フィンランドスウェーデン【バルト】 (252)
★Armour Modelling アーマーモデリング★44 (961)
☆彡　ＧＣ．ＦＭ仕様他　族車プラモ☆彡 (498)
--log55.com------------------
チラシの裏 Part.2
彼女が出来ない原因のほとんどはこれ
◇二人だけがわかる単語◇ Part.9
一番辛かったことは
私が悪いんだけどそこまで言わなくてもいいんじゃないかと…
嫉妬してしまうこと
ショックだったこと！
つい疑ってしまうこと