まず、漏れは Ruby を推したい。
内部イテレータのおかげで、短いコードでデータの取得、メモリの解放が可能だ。
Perl や PHP はオブジェクト指向の機能が不足である。Javaやは型宣言を
せねばならず、ムダにコードが長くなる。保守性は悪くなる。
つまり、Javaは別の分野で用いるべきである。
.NETやPythonは知らないが、.NETはJavaの片割れでたいしたメリット無いみたいだし、
PythonはRubyのライバルとされているが、どうか。イテレータの書きやすさは Ruby のほうがいいな。
データベース呼び出してるところのソースを載せていただけると
ありがたい。
ttp://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 と文字列処理に強いかってのはあんまし関係ないと思うぞ。
RDB/SQL をデータの格納と取り出しだけの存在とみなすならいいのだけど、
実際には複数テーブルを join して集計したりと、
業務ロジックと密接な処理を SQL を用いて行う場面が多い。
そういった SQL/その RDB でできることをできる限りカバーしようと考えると、
プログラミング言語のライブラリ側に
SQL とほぼ一対一で変換できるようなオブジェクト
(Criteria オブジェクトとか良くあるけどさ) を導入することになる。
が、OR マッピングのライブラリの仕様はまちまちだし、
はまだ SQL でできる範囲をカバーしきれていないので、
それなら SQL をそのまま使った方がいいというのが現状。
結局エンティティクラスのコンストラクタの引数に渡すか
作ったインスタンスにセッターメソッド使って値を代入することになるので、
それなら直接インスタンスになってくれた方がありがたい。
いや、自明のことというか、大ありだと思うんだが
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
>
> ソースと掛けてるのか？( ´,_ゝ｀)ﾌﾟｯ
お客様にお願いいたします。
釣りもしくは自演をなさるのならせめて 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なわけだが何か？
ttp://www.ara.or.jp/e/e_index.html 知ってるが、それが何か関係ある？
何でそう莫迦なの？
2. 「SQL を、整形せずに埋め込める言語は？」の問いに
「SQL」と答える間抜けさ。
3. SQL はプログラミング言語ではない。
取り敢えず は PL/SQL (サーバサイド) ないし
Pro*C (も言語じゃないが。クライアントサイド) でも使えと。
ただし、Turing Completeではないだけ。
でも言語の選択よりもバインディングがしやすいかどうかのほうが重要な気がする。
だから、SQL自体もプログラミング言語なんだから、
SQLで完結しろと言うことだろ？
第一、PL/SQLの立場がないじゃないか。
>100
>SQLで完結しろと言うことだろ？
バッチ処理しかしないのかッ！
業務にSQLPLUS以外は使わせない！ というのはどう？
この言語は五本指くらいには入りますか。ほかしらないので・・。
重くて煩雑なスクリプト言語の五本指か？
char *table;
table := "社員";
select 'A',"所属","社員番号","社員名" from table;
が書ける言語かな。
./ ノ 人 ヽ ヽ
＿_ ./ ／／ ヽ ヽ .ヽ ／￣＼
.／ ○ ヽ､ / （＿_） （＿） ヽ／ ○ ＼
／ ＼,,,--―――''''''''''''''''''''――-／ ヽ
..⌒‐-,,,,_ /:/ヽー―――-、,,__,,,,-―――:|| _,,;-‐''"⌒~~~
.ヽ/::||:::::::::: （●） （●） ||／ヽ
く ::||::::::::::::::::: ＼＿＿_／ ||:::::::::ヽ
ヽヽ:::::::::::::::::::. ＼／ ノ＿／
駅に飾られるとか飾られないとか。
ttp://messages.yahoo.co.jp/bbs?action=m&board=1835157&tid=bebekdcbfmbbvbana4ngp6g&sid=1835157&mid=1 要するに文字列操作をしなくてすむ言語が「最適な」資格を持つと？
にとって。
Oracle なら PL/SQL か、Pro*C って選択はあり。
埋め込みSQLが使えるものがあったが、最近見なくなった。
select (ename,empno,deptno) from emp が許されなかったり、
where #job=clerk でよかったのに job='clerk' とした。
ほかの言語の構文規則と衝突したり、曖昧さを克服し難くした。
型定義マストとなるとねー
while(result.hasNext()){
Map personData = (Map)result.next();
Integer age = (Integer)personData.get("age");
..
みたいなのいるわけでしょ。なんかコードが長くなるだけで、メリットが無いと思う。
キャストがめんどくさいってんで、なんかクラスをわざわざ定義してマッピングするなんてこと
やると死ぬほど逆にさらに面倒で。それを自動化するライブラリを使うと、
さらに悲しいことに、マッピング方法を勉強したり、それで設定ファイルを書いたり、
マッピングするライブラリの仕様変更にあわせて、それを使ったソフトも更新しなきゃいけないし、
泥沼よ。
データ格納するだけなんだから、それに適した型をHashMapを使えってなもんだ。
result.each { |person|
age = person[:age]
}
これでいいじゃん
そうすれば、このスレの解も決まる。
データベースプログラミングでより重要なことは全解の取り込みを想定しての、
動的なメモリー管理や、リスト処理のしやすさではないだろうか。
「全解の取り込み」ってのは謎だが
メモリ管理・リスト処理なんつーのは別にデータベースプログラミングに限らず超重要事項というか、
データベース処理では確かにリストの扱いが楽なほうがいい。
OPOはDEVELOPER2000との社内抗争に負けて消えていきました。
(安定性とか制限の少なさとか)って観点ではどんなもんでしょ？
例えば、jdbcとRuby/DBIを比べると、
特に相手がOracleなんかだとRubyでは↓こういう
ttp://www.jiubao.org/ruby-oci8/index.ja.html αバージョンのドライバしか出てないけど、
jdbcだったらOracleから正式にドライバが出てるからjdbcの方が安心だな、とか。
相手が Oracle なら Pro*C 最強。
そういう、PHPに不利なルールを持ち出すと、暴れる人が出てきちゃうよ。
思っちょります。
ただ、いかんせんVisual系言語はまったくのど素人で、どなたか、
VisualC++からPostgreSQLのデータを読み書きするための
サンプルプログラムなんぞあったら、あるいはここにある、ちゅうのを
教えてもらえるとありがたいです。
たぶん、ODBCを使うんだろうぐらいは考えているんですが・・・。
ちなみに当方の技術レベルは、こんなかんじです。
●ORACLEのDBA
（ORA-600などの内部エラーをサポセンとやりとりしながら対処するぐらい）
●C言語中級者の下（構造体まで。ポインタほぼ全滅）
●シェルスクリプトで作りたいものが作れる
あと、ポインタもわかってない奴は中級とは言いませんので、
うぬぼれるのもいい加減にしてね。
つか、ポインタもわかってないやつが、PostgreSQLのインターフェース
使えるようになるとは思えんが。
人を罵倒するだけして、けっきょく建設的な話は全く出さないんだね。屑人間っぽい。
死んでくれ。
質問してくるような頭の持ち主は
どこにでも湧いて出る。
ActiveRecordをググって調べてこい
どちらに主眼をおくかで最適の基準が変わってくる。
あとはプラットフォームへの依存性の有無も評価が分かれるところだ。
時々好きな人がいるからおっかないけどさぁ、あんなものどこが良いわけ？
かってにいろいろやってしまう要素が少なく安定してパフォーマンスが良い
プログラムが書ける。欠点は構文の仕様が古すぎる点とデバッガやIDEなどが対応
してるものがまれだという事。Oracleはなぜか以前から埋め込みSQLが好きみたい
で、SQLJがjavaの規格に追加されたのもOracleのプッシュがあったからと聞いたこ
とがある。真偽は確かめてないけどね。
組みやすいんじゃないか？比較的に
よく知らないから効率が悪いというのは言語が最悪だからとは言わんぞ。
大量データを効率的に管理できるかというと、無理っぽい。
個人商店なんかだったら、まぁ行けるだろうけど。
VBやWebで専用クライアント作った方が身のため。
ACCESSのプロジェクトファイルを知らないのですね！（ ´,_ゝ｀）ﾌﾟｯ
「VB」といった時点でたいした（ry
SQLServer買わなくいいだけましか。
そんな貧乏な貴方にオススメなのがMSDE！
今ＶＩＰと韓国サイバーテロ集団が火花をあげて戦っています！
この夏の思い出作りに是非貴方達ももこの祭りに参加しませんか？
↓↓↓詳しくはは↓↓↓
ttp://ex11.2ch.net/test/read.cgi/news4vip/1124442853/ ご協力、よろしくお願いします。
605 ：オーバーテクナナシー：2005/06/22(水)20:08:36ID:7MAgOv1F
>603
森の中では飛び道具より待ち伏せして槍で襲うほうが効率的。
飛び道具だとはずしたとき穂先の石が割れてしまいます。
この方法に切り替えることで黒曜石資源が節約できます。
そういえば、原始人さんたちは現生人類ですか？
606 ：聖女◆9RaBw0NoLw：2005/06/23(木)18:24:23ID:+/a6UT8F
防具や回避手段の開発も早いほうが良いですよ。
607 ：オーバーテクナナシー：2005/06/23(木)19:33:26ID:HGQMIB5O
？>605
超至近距離まで近づき、下手すれば反撃を食らう可能性のある槍の方がいいの？
資%
このスレでPerlやRubyが候補に挙がることは、
データベース検索とWebが結びついていることが
多くなった証拠と考えて良いのでしょうか。
ところで、COBOLやFORTANからRubyを経由して
データベースにアクセスに行くと言うような
ことは簡単にできるのでしょうか。
ここの部分を担えないと言語仕様がデータベース
向きでも、最適な言語とは言い難いように
思います。
COBOLやFORTRANから直接DBアクセスできるように下ほうがいいでしょ。rubyを経由する方が面倒。
文字の扱いはjcode想定？ 自前で便利なように拡張してればあんまり言語の差はない。
それぞれのDBのAPIを直接覚えなくて済む程度の利点？
もうひとつが、SQLで表現しにくい部分の処理。
ハンドリングのよい言語に担わせる。
そういう意味ではRubyなんて洒落てる。
現在のISO標準仕様でいじくってもだめ。
まったく別構文でデータベース用言語として、
設計し直せば有力か。
ISO標準仕様だと
?- select * into X from emp
where job=cleek,
member(A,X), ・・・ これは可。
?- select ename,empno,deptno into X from emp
where job=cleek,
member([A,B,C],X),・・・ これは不可。
?- select (ename,empno,deptno) into X from emp
where job=cleek,
member([A,B,C],X),・・・ こうすれば可。
要するにカンマの使い方を考え直さないといけない。
連言を","ではなく∧で表せば本格的だが、キー入力が大変。
clerkと'clerk'の差異も判別できない。
金とるなら、WebLogicでも使って儲けた方がいいし(w
とりあえずヘルパークラス書いて、使う分にはこんなかんじ。
まあなんだ、C++でもPerlでも記述そのものに大きな差があるとは思えないな。
文字列加工もasprintfで十分だし、正規表現を使いたいならpcreを入れれば済む話だ。
でもDBIみたいなのが普及してないのは確かに面倒かもしれん。
DB_Connection conn;
if( ! conn.open("foo.db")
|| ! conn.setCryptKey(password)
){
printf("error=%s\n",conn.getError());
}else{
DB_Query q;
if( conn.query(q
,"select * from t1 where hoge=? and name=?"
,"LT",(__int64)hoge,name
/* 可変引数でバインドパラメータを設定する */
)){
while( q.getNextLine() ){
int cols=q.getColCount();
for(int i=0;i<cols;++i){
DB_Column c = q[i];
printf("col[%d]=%s\n",i,(const char*)c);
}
}
}
if( q.hasError() ) printf("error=%s\n",q.getError());
}
if( ! conn.close() ){
printf("error=%s\n",conn.getError());
}
それはプログラミングとは言わん。
ここのスレタイをよく確認するんだ。
"データベースプログラミングに" 最適な言語は何か なので、
"データベースプログラミング言語に" ではない。
従って、口頭で指示して目的が達せられれば、それにこした事はない。
文句一つ言わず動いてくれるPCさえ使いこなせないのに人を使うなんて無理。
部下もうまく動かないことも有るので、同じ仕事を別の部下に指示してRAC構成で使ってるよ。
部下が風邪引いて病欠でも、出社している部下が問題なく処理してくれる。
復活してほしい！
dbXLもFoxProもあるんだが？
個人的にはなにをいまさらって気がする。
英語に自信があるなら
ttp://www2u.biglobe.ne.jp/~objxbase/ ないのなら
ttp://www.soupacific.com/products/index.html 英語のマニュアルがバリバリ読めるのならFoxPro使うけどなあ？
試しにFoxProとAccessをGoogleで検索すると圧倒的にFoxProのほうが多い。
マイクロソフトは日本市場なんてAccessで十分なんだと・・・・・
やはり使うならFox proでしょうか？
仕事で他のみんなAccessでやってますが、いちいち邪魔くさいので、
我輩は未だにV_dbaseの最終版v7.1でせこせこやってます。
最後はexcelでデータを出すので、何使ってもいいのですが、なにせ
終わってから５年以上、、、、。まだ使えると思うのですが。
> やはり使うならFox proでしょうか？
だから、あなたが英語の技術文書くらい読めるぞってなら、迷わずFox proだと思う。
英語のMLに入って質問できるくらいなら、世界中にお友達はいっぱいいる。
情報に不足はないはず。
英語が苦手ならdbXL。
昔の勢いは無いみたいだけど、サザンパシフィックの製品は悪くない。（少なくとも昔は）
別にシステム開発しているわけじゃないんでしょう？
だったら、桐も検討をお勧めする。
ちょっとしたものをちょこちょこと書くならdBaseよりはるかに簡単だし、
エクセルとの親和性も悪くない。
漢字でプログラムを書くのが最初は違和感があるかもしれないけれど、
エクセルのマクロのように操作手順を覚えこませて、
そのままプログラムの一部とするなんてことが出来てしまう。
お気楽さは最高。
体験版がダウンロードできるから試してみたら？
かの昔、DOS時代に桐ｖ３は少しかじりました。そいで、dbaseに移り、DBXLも
QuickSilverを駆使して、プログラムしてました。その後、V_dbaseで書き上げたのですが、
日本で終わって、我輩のプログラミングも終了。
今は分析ツールとして使っている次第です。
サザンのＡＲＡＧＯも初期は触っていましたが、今は、、、、です。
一度、桐を体験してみます。ＦＯＸｐｒｏの体験版はないのでしょうか？
> かの昔、DOS時代に桐ｖ３は少しかじりました。そいで、dbaseに移り、DBXLも
> QuickSilverを駆使して、プログラムしてました。その後、V_dbaseで書き上げたのですが、
かの昔のさらに昔、CP/Mの時代にdBASEIIを始め、Basicをはるかにしのぐ生産性に感動。
その後、QuickSilverまでは良かった。Windows時代になって、dBASEはもちろんのこと
他のデータベースもさっぱり出てこない。やっと出てきたAccess1.0。なんじゃこりゃ？
と思いつつも他に変わるものも無し、しかたなく使い続けて現在に至る。
その他、桐、dBMAGICなどもかなり使いました。
dBASEの良さを知りつつも、あまり戻る気がしないのは、やっぱりSQLの存在が大きい。
大雑把に言ってしまうと、VBAでSQL動かせば大半の処理は済んでしまう。
dBASEのように基本的に１レコードずつ処理するのとはスピードがぜんぜん違う。
入力はフォーム、出力はレポート、途中計算はVBAでSQL文を実行させて処理とすると決めると、
Accessも割と使いやすい。Accessが難しいのは機能が多すぎてしかもダブっていること。
使わないものは思い切って無いものとして割り切ると習得は早いと思う。
> 一度、桐を体験してみます。ＦＯＸｐｒｏの体験版はないのでしょうか？
バージョンアップの時期にはたいてい出すようですけど、今はないみたいですね。
ごもっとも！確かにＳＱＬを埋め込んですると、早い早い。（まわりは
dbaseで固めてますけど、、、。）
＞使わないものは思い切って無いものとして割り切ると習得は早いと思う。
未練がましくやっている俺って、、、、。
色々とご助言ありがとうございました。
Visual Objectsというのもあります。Xbase系の言語＋オブジェクト指向の
拡張がなされ、1994年に登場。v1の時にダブルバイトサポートを組み込み、
v2の時に言語の識別子のダブルバイトサポートを組み込んでいます。
現行バージョンはよく知らないけど、Xbase系の生き残りです。
ttp://www.cavo.com/ 体験版は、
tp://grafxsoft.com/VO_25_Trial_Version/VO_25_Trial.zip
ラムダ式に似たCodeblockという機能を持っていたり、
オブジェクトの配列名に対してメソッド実行すると全要素に呼び出しがかかるとか
スーパークラスに存在しないメソッドを勝手に定義できるとか
かなり変わり者の言語です。
日本では1997年に開発元の日本法人がサポート終了・販売終了にしたので、
成長過程を断ち切られた形になりました。
・・・
メモリリソースが潤沢な現在のコンピュータ環境の場合、
DBFの処理もかなり高速に実行できると思います。
全レコードをいったん読んでしまってメモリ上にキャッシュしてしまえば、
単純な集計処理ならあっという間に終わるでしょう。
クライアントＰＣのパワーを使うなら、Xbaseの処理系を併用するのも意味が
あるので、RDBMSだけに頼らなくてもいい面だってあると思います。
FoxProの海外事例なんかがそうですが、SQL ServerとFoxProデータベースの
併用によりシステムを構築しているものがあります。
Xbaseに未練があってもいいかも。
SQL鯖＋エクセル
SQL鯖＋アクセス
でも割と使えますが？
若者はRubyかPython
汚ねぇコードでも気にならない奇人はPerl
プロ根性のないやつはVB
君が低レベルなWeb屋なのは判った。
あいつらの頭は進化が止まってる化石。インターネット対応なんて考えが及ばないし。
昔から遣ってる香具師は、ProCとか。最近始めた香具師は、JavaとかPHP。
それより データベース言語 = Prolog なのだから
はPrologを否定することからこのスレを始めるべきでした。
ストアドプロシージャ使わせてくれないからそうしてたけど。
組みあがったSQL検証するためにデバッグ出力しないといけなかったり。
SQLは集合を扱うことに特化した非手続き型言語とみなせば業務ロジックの殆どはSQLだけで実装できる。
苦手なのはI/O。表現力は貧弱。
だからストアドさえ呼べれば、アウトプットの編集に最適な言語が最適。
WEBならPHP?でもPHPコードが増えるとHTMLの原型留めなくなるしなー
帳票はCOBOL?カンマ編集とか必要になるとスクリプト言語で書きたくなる…
プロジェクトはパッケージソフトなんで・・・
SQL ML Prolog がデータベースを論じるときの基本言語と
昔から決まっている。ML Prolog の限界を語り尽くした後に
DBMSとの繋ぎ言語を対象とするべきとわたしも思う。
ＤＢ特化言語って、命令が色々そろってて便利だけど、何かしら不得手部分が出てくると、そこを何とかするのにえらい苦労させられた思いが強い。
Ｃでコツコツが、結局は一番な気がする…
ちょっと関係ないかもしれないけど、
WikipediaのPL/SQLを読んでみて、OracleのOCIに
関する言及がまったくないのに驚いた。なにが違うかは
大事なところだと思うが。
ウィキはそーゆーもんだ
可読性高いしメンテも楽。
SQLの穴埋めするのに何バイト目とかカウントしなくて済むRubyが楽だお。
人間、楽をするとろくなことがないよ。
目先の労力のことではなく、
人間性の形成の話だけどな。
苦労を厭わず飛び込んでいく香具師のみが
人として幸せになれる。
私も昔はそのように思っていましたが、
ただ自分の仕事が増えただけで、幸せにはなれませんでした。
常に楽が出来るように考えたほうが、人として幸せになれる。
短気
傲慢
がプログラマーの三大美徳。
楽しようとしない香具師は向いてないだろ。この仕事。
何言ってんの。
自分の仕事が増えるってことは
他人より信頼されて任されてるってことでしょ。
プロとしてこれほど名誉なことはないじゃない。
仕事なんて、気の持ちよう一つで
天国にも地獄にもなるよ。
楽しようとして苦労するんだけどな (w
楽ばかりして、コードを書く量が減るのはダメでしょ。
やりたいことができるなら、コードなんか少ない方がいいと思うぞ。
(スパゲッティになるとか、perl の呪文みたいな無理矢理圧縮は別にして。)
昨日入力数(_部署,_入力数)
:-
部署(_部署),
昨日(_昨日),
select count(*) into [[_入力数]]
from 総勘定元帳
where 部署=_部署 and
処理日=_昨日.
部署(本社).
部署(関西支社).
%%% 実行例 %%%
?- 昨日入力数(A,B).
A = 本社,
B = 37.0;
A = 関西支社,
B = 8.0;
no
?-
{ '総勘定元帳の部署が%t、処理日が%tのデータ数は',[_部署,_昨日],[[_入力数]] }.
部署(本社).
部署(関西支店).
%%% 実行例 %%%
?- 昨日入力数(A,B).
A = 本社,
B = 37.0;
A = 関西支社,
B = 8.0;
no
?- というのもある。表記法の事例として見てください。
{ }のなかの第一引数を解析するのだがこの部分はあまり
難しくはない。木構造を作れたら、対応するselect文の
パターンを引き出す。ただし、このライブラリは最近手を
付けたばかりで未完成です。
あることを暗示したいのですね。
DB以外の要求機能のほうが重要だったりするし。
どうせ、networkとかIOが足引っ張るし。
なにより、スレッドの同期とか楽なんだもん。
C+pthreadよりは間違いなく楽。
java.util.concurrent使えるなら、もっといい。
DBMSを書くためということですか?
それとも
DBMSの中のアプリ(例えばSQL+)を書くためということですか?
ホント Pro*Cからecpgへの移行は地獄だぜ！ フゥハハハーハァー
プレゼンで見せる時はphpだけどな(w
jdbcも結局は独自発行コマンドを駆使するから、簡単にはDBは変えられない。
GUIで画面構成とかプロパティがんがん決めれて、
RowSourceにSQLつっこめばレコード返してくれる
ACCESS+SQL Serverが一番楽な気がするのですが、
これより楽なのありますか？
Webサービスでは求められる物も答えも違うだろ。
どの場合においてもRubyじゃ無いことだけは確かだが。
ADO.NETつかうなら、どれもあんまり変わらない気がする。
SuperCon2007 ― 夏の電脳甲子園
ttp://pc11.2ch.net/test/read.cgi/tech/1181916316/ 1 ：デフォルトの名無しさん ：2007/06/15(金) 23:05:16
がんばれっ！天才高校生諸君
スーパーコンピューティング・コンテストSuperConは、
高校生がスーパーコンピューターを使って、プログラミングのアイデアを競う大会です
今年は阪大に今年導入された最新のスーパーコンピューターを使います
プログラミング大好きな高校生諸君！
来たれ阪大・東工大へ！！
諸君のアイデアをスーパーコンピュータ上で実現してみよう！！！
ttp://www.gsic.titech.ac.jp/supercon/supercon2007/index.html ?
ttp://www.ine.sie.dendai.ac.jp/homepage/ ttp://www.ine.sie.dendai.ac.jp/wiki/index.php?FrontPage バッチ処理とかそこだけperlとかで書くのかな。
Javaいいけど、サーブレットにすると更新するたびに再起動とかサービス止まるじゃん。
大手ポータルやSNSが採用してる
perlかPHPじゃねーの
個人的にはCで良いよ。
パフォーマンスで劣ることはないし
出来ないことはないし
スクリプトだなんだと言うならobjectCにしる。
でもやっぱり文字列処理とメンテナンス性とったら
PHPかな。
なんすかその人工無能が書いたような文は
ttp://game14.2ch.net/test/read.cgi/575/1010948472/l50 もう4th Dimensionしかねぇな。
他のDBじゃ目が回っちまうぜ
4Dだけはやめとけ
勇者光臨
やめとけ｡死ぬぞ｡
ADOはどうなんですか？Connectorだけ切り替えればいけるのかな？
Prologをオンメモリデータベースとして強化すれば、
それだけでいいんじゃないの。
perlやpythonも齧ったんだが、馴染めなくてな。
10年以上PowerBuilder使い続けてるよ。
IDE も賢くなってるし、膨大なライブラリが
あるので結構楽だったよ。
ただ現状ではまだ配布が面倒なので自分用の
ツールにしか使ってないけど。
IDEってなに？
ｸﾞｸﾞﾚｶｽ
ロゴ・ダウの遺跡
たぶんこう使うんだろう、
でそのまま使えて驚きですわ。
うわぁぁぁ、それって今は亡きボーランドのDB専用プログラミングパッケージだったけ？
大昔にパラドックスっていうRDB買ったせいか、チラシ送ってきたっけ。
ttp://grails.org/GORM こいつの生産性はメチャクチャ高い。
ただし、価格がこれまたメチャクチャ高い。
遅レスだがSYBASEだろ
なぜか日本ではSYBASEで売ってないw
生島勘富とかいう奴
・VB6+ODBC
・C#+SQLite.net
・PHP+Pear::DB
・CakePHP
この中じゃCakePHPが圧倒的に楽だったよ。
Prolog
?- foo(id:X,data1:'長野県上水内郡信濃町',data2:Y).
X = '023449',
Y = '大字富濃2306'
yes
?-
?- mysql(Mysql),Mysql :: foo(id:X,data1:'長野県上水内郡信濃町',data2:Y).
X = '023449',
Y = '大字富濃2306'
yes
?-
上側の一般的なProlog照会と下側のデータベースシステムに対する照会が構文的に
まったく同一でいけるという意だと思うが、
Prologの単位節データベースの引数に id1:'023449' のような構造体(:がfunctor)を
持つことは、単一化の総コストが大きくなりすぎて、現実的(実用的)ではないのではないか。
現在のPrologの仕様では
・ 節の順序を変更することのないupdateが難しい。
・ 数十万を越えるような連続したassertが想像以上に時間がかかる。
それと、
下のPrologの副目標として、データベースシステムを参照にいく場合とは、
元々Prologの述語としてデータベースがあり、
そのコードをデータベースシステムの照会にそのまま借用したいということだろう。
この場合通常、Prologの副目標は最初にテーブルの参照があって、その後に
単一化された引数の検査という順序で書かれている。一方、このコードをSQL文字列に
変換するとなると、sql文を発行する時点で、where句の条件を知っていないと効率の
良い照会にはならない。
つまり、テーブルの参照は遅延しておいて、その後の副目標群の解析を先に進める必要が
ある。そのためには、どこまで解析すればよいのかを示す何かが必要になり、多くの場合、
ブロック構造が導入されることになる。
この時点で少なくとものコードそのものではなくなる。
ブロック構造で翻訳を指示したとしても、
SQL参照と無関係な副目標が存在することも多く、編集を
余儀なくされるというケースはあります。
オペレータ定義を駆使しても、
select id,data from foo というような表現できません。
select (id,data) from foo ならOKですが、これだとSQLの方で構文エラーになります。
本当にデータベースシステムと双方向に一体化するためには
エジンバラ版Prologを放棄した方がよいと思います。
連接を表すオペレータを"&&"に変えてみる
?- member(_組,['A','B']) && select 学年,組,名前,性別,生年月日,住所,電話番号 from 学籍簿 where 組=_組 and substr(住所,1,3)=東京都.
これだけでよいのかな。
属性名と属性値を区別するオペレータが必要になる。
暗黙的な解釈としては、式の左項は属性名、右項は属性名でよいが、
結合の時に、共に属性名であることを明示しなくてはならない。
t1.氏名 = t2.氏名 の
t1.氏名 がsyntax errorになる
処理系もありそう。本来は
t1.f1 = [t1|f1] となってエラーにはならないはずだが。
それだと、組が'A'の場合しか表示されない。
やはり、最後に && fail. が必要。
面白くない。もともと、それに特化した言語だからね。
このスレタイでも、Rubyがあがっているように、もう少し捻った
議論はないものか。
ということになると、やはりCかな。
プログラム本体にSQLベタ書きじゃなくて中間言語を呼び出し
中間言語にSQLやストアドに変わる部分を書き出し
データベースは純粋に中間言語からの命令だけ受けるようにする
まあ、javaのアレみたいな思想だ
こうすればDBMS依存がかなり減る
DBメーカーも、古い仕様を引きずっていくのは大変だね。
それをネットでリアルタイム配信
仲間という人間に対する盗聴盗撮生ネット配信の会
しかけたカメラの映像
乗っ取っているＰＣの画像をリアルタイムで生配信中
集団で仲間の私生活を覗いて楽しんでいる
そんなことが今この国では行われています
デフォが文字列型で、オプションで自動判定出来るようにすりゃいいだろ!!
スキーマini作るのメンドイんだよぉぉぉぉぉ!!
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
A5N98F9MTR
改憲議員が３分の２を超えております。『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆
正解でしょ
と言うかMy SQLもその派生のMariaDBも糞だけどね
おまえww
オラクルに親殺されたの？
