データベースプログラミングに最適な言語は何か
データベースプログラミングに最適な言語は何かを論じたい。 まず、漏れは Ruby を推したい。 内部イテレータのおかげで、短いコードでデータの取得、メモリの解放が可能だ。 Perl や PHP はオブジェクト指向の機能が不足である。Javaやは型宣言を せねばならず、ムダにコードが長くなる。保守性は悪くなる。 つまり、Javaは別の分野で用いるべきである。 .NETやPythonは知らないが、.NETはJavaの片割れでたいしたメリット無いみたいだし、 PythonはRubyのライバルとされているが、どうか。イテレータの書きやすさは Ruby のほうがいいな。 >>106 このてのはなし、少し前にもあったけど 要するに文字列操作をしなくてすむ言語が「最適な」資格を持つと? >>110 >>84 にとって。 Oracle なら PL/SQL か、Pro*C って選択はあり。 その昔、Oracle Power ObjectというVisual Basicもどきでoracleの 埋め込みSQLが使えるものがあったが、最近見なくなった。 >>110-112 埋め込むとなると、いかにもSQLの仕様が悪い。 select (ename,empno,deptno) from emp が許されなかったり、 where #job=clerk でよかったのに job='clerk' とした。 ほかの言語の構文規則と衝突したり、曖昧さを克服し難くした。 埋め込み型はWHENEVER xx GO TO や SQLCODE などエラー処理まわりがいかにも古めかしい。 >>99 型定義マストとなるとねー while(result.hasNext()){ Map personData = (Map)result.next(); Integer age = (Integer)personData.get("age"); .. みたいなのいるわけでしょ。なんかコードが長くなるだけで、メリットが無いと思う。 キャストがめんどくさいってんで、なんかクラスをわざわざ定義してマッピングするなんてこと やると死ぬほど逆にさらに面倒で。それを自動化するライブラリを使うと、 さらに悲しいことに、マッピング方法を勉強したり、それで設定ファイルを書いたり、 マッピングするライブラリの仕様変更にあわせて、それを使ったソフトも更新しなきゃいけないし、 泥沼よ。 データ格納するだけなんだから、それに適した型をHashMapを使えってなもんだ。 result.each { |person| age = person[:age] } これでいいじゃん >>113 SQL言語を遅延評価付の制約論理型言語に置き直す。 そうすれば、このスレの解も決まる。 >>1 の内部イテレータは表現上の"洗練"ということだと思う。 データベースプログラミングでより重要なことは全解の取り込みを想定しての、 動的なメモリー管理や、リスト処理のしやすさではないだろうか。 >>118 「全解の取り込み」ってのは謎だが メモリ管理・リスト処理なんつーのは別にデータベースプログラミングに限らず超重要事項というか、 データベース処理では確かにリストの扱いが楽なほうがいい。 >>112 OPOはDEVELOPER2000との社内抗争に負けて消えていきました。 言語の話から逸れるけど、接続インターフェースのデキの良さ (安定性とか制限の少なさとか)って観点ではどんなもんでしょ? 例えば、jdbcとRuby/DBIを比べると、 特に相手がOracleなんかだとRubyでは↓こういう http://www.jiubao.org/ruby-oci8/index.ja.html αバージョンのドライバしか出てないけど、 jdbcだったらOracleから正式にドライバが出てるからjdbcの方が安心だな、とか。 >>122 相手が Oracle なら Pro*C 最強。 >>122 そういう、PHPに不利なルールを持ち出すと、暴れる人が出てきちゃうよ。 PostgreSQL + VisualC++.NETでGUIベースのアプリを作ろうと 思っちょります。 ただ、いかんせんVisual系言語はまったくのど素人で、どなたか、 VisualC++からPostgreSQLのデータを読み書きするための サンプルプログラムなんぞあったら、あるいはここにある、ちゅうのを 教えてもらえるとありがたいです。 たぶん、ODBCを使うんだろうぐらいは考えているんですが・・・。 ちなみに当方の技術レベルは、こんなかんじです。 ●ORACLEのDBA (ORA-600などの内部エラーをサポセンとやりとりしながら対処するぐらい) ●C言語中級者の下(構造体まで。ポインタほぼ全滅) ●シェルスクリプトで作りたいものが作れる スレ違い。 あと、ポインタもわかってない奴は中級とは言いませんので、 うぬぼれるのもいい加減にしてね。 つか、ポインタもわかってないやつが、PostgreSQLのインターフェース 使えるようになるとは思えんが。 >>127 人を罵倒するだけして、けっきょく建設的な話は全く出さないんだね。屑人間っぽい。 死んでくれ。 突っ込みどころ満載だが、スレ違いなのでぐっと我慢しておこう まあ質問スレでもないのに 質問してくるような頭の持ち主は どこにでも湧いて出る。 て言うか、ググルなりポスグレのユーザー会のページに行ってマニュアルダウンロードするなりすることもできない奴を相手にしてもしょうがないよね。 上でRuby Ruby言いながら素のDBIしか使う頭のないやつは ActiveRecordをググって調べてこい 操作性とパフォーマンスが両立しないことが多いから どちらに主眼をおくかで最適の基準が変わってくる。 あとはプラットフォームへの依存性の有無も評価が分かれるところだ。 仕事でSQLJを使わされているんだけどさぁ、最低最悪ですわ。 時々好きな人がいるからおっかないけどさぁ、あんなものどこが良いわけ? 埋め込みSQLはDBの下位APIと相性が良くて、プログラマーから見えないところで かってにいろいろやってしまう要素が少なく安定してパフォーマンスが良い プログラムが書ける。欠点は構文の仕様が古すぎる点とデバッガやIDEなどが対応 してるものがまれだという事。Oracleはなぜか以前から埋め込みSQLが好きみたい で、SQLJがjavaの規格に追加されたのもOracleのプッシュがあったからと聞いたこ とがある。真偽は確かめてないけどね。 最悪と言うが、何と比べて最も悪いと言ってるんだろうか? よく知らないから効率が悪いというのは言語が最悪だからとは言わんぞ。 Accessは、業務フローをそのまま作るには楽だけど、 大量データを効率的に管理できるかというと、無理っぽい。 個人商店なんかだったら、まぁ行けるだろうけど。 AccessをクライアントにしてMySQLをサーバにしてもダメ? Accessで何か操作をしたときに、どれだけ重いクエリが投げられると思ってるんだ。 VBやWebで専用クライアント作った方が身のため。 >>144 ACCESSのプロジェクトファイルを知らないのですね!( ´,_ゝ`)プッ AccessをクライアントにしてMySQLを操作する話だろ。 MySQLの利点を何もかも台無しにするけどな。 SQLServer買わなくいいだけましか。 >>148 そんな貧乏な貴方にオススメなのがMSDE! 緊急告知! 今VIPと韓国サイバーテロ集団が火花をあげて戦っています! この夏の思い出作りに是非貴方達ももこの祭りに参加しませんか? ↓↓↓詳しくはは↓↓↓ http://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でいい。 久しぶりに上がってきましたね。 このスレでPerlやRubyが候補に挙がることは、 データベース検索とWebが結びついていることが 多くなった証拠と考えて良いのでしょうか。 ところで、COBOLやFORTANからRubyを経由して データベースにアクセスに行くと言うような ことは簡単にできるのでしょうか。 ここの部分を担えないと言語仕様がデータベース 向きでも、最適な言語とは言い難いように 思います。 webならjavaベースのwebアプリケーションソフト使った方がラク。 COBOLやFORTRANから直接DBアクセスできるように下ほうがいいでしょ。rubyを経由する方が面倒。 文字の扱いとメンテナンス性考えたらやっぱperlじゃね? 自分のソースを自分でメンテするならperlでも問題ないけど、人のperlのソースはメンテキツいよ。 文字の扱いはjcode想定? 自前で便利なように拡張してればあんまり言語の差はない。 DBIで抽象化ってアイデアはいいけど、結局は裏で動いてるのがMySQLなのかOracleなのかで大きくパフォーマンスが変わって仕舞う罠。 それぞれのDBのAPIを直接覚えなくて済む程度の利点? ひとつには抽象化。 もうひとつが、SQLで表現しにくい部分の処理。 ハンドリングのよい言語に担わせる。 そういう意味ではRubyなんて洒落てる。 >>162 現在の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'の差異も判別できない。 どうも決定打に成るのは無いので、自分で使いやすいクラスをRubyで作った方が速いと言う結論に達した。 金とるなら、WebLogicでも使って儲けた方がいいし(w 問い合わせ処理と一般的なロジックを同じ平文で記述できるdBASE言語が最強。 最近はVC++からsqlite3を使ってる。 とりあえずヘルパークラス書いて、使う分にはこんなかんじ。 まあなんだ、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()); } 部下に日本語で指示 これがまさしく最強最適(たまにこけるが、、、) >>173 ここのスレタイをよく確認するんだ。 "データベースプログラミングに" 最適な言語は何か なので、 "データベースプログラミング言語に" ではない。 従って、口頭で指示して目的が達せられれば、それにこした事はない。 プログラムを発注する作業はプログラミングとは言わん。あほか。 でも自分で抱え込んで組んでたら時間がいくら有っても足りないから、うまくforkしまくって、頻繁にプロセス通信して指示して修正して進めた方が負荷は下げられるし、30超えても生き残れる。 人を使うのはPGには無理だと思う。 文句一つ言わず動いてくれるPCさえ使いこなせないのに人を使うなんて無理。 部下もうまく動かないことも有るので、同じ仕事を別の部下に指示してRAC構成で使ってるよ。 部下が風邪引いて病欠でも、出社している部下が問題なく処理してくれる。 >>183 dbXLもFoxProもあるんだが? 個人的にはなにをいまさらって気がする。 >>185 英語に自信があるなら http://www2u.biglobe.ne.jp/ ~objxbase/ ないのなら http://www.soupacific.com/products/index.html 英語のマニュアルがバリバリ読めるのならFoxPro使うけどなあ? 試しにFoxProとAccessをGoogleで検索すると圧倒的にFoxProのほうが多い。 マイクロソフトは日本市場なんてAccessで十分なんだと・・・・・ ありがとうございます。 やはり使うならFox proでしょうか? 仕事で他のみんなAccessでやってますが、いちいち邪魔くさいので、 我輩は未だにV_dbaseの最終版v7.1でせこせこやってます。 最後はexcelでデータを出すので、何使ってもいいのですが、なにせ 終わってから5年以上、、、、。まだ使えると思うのですが。 >>187 > やはり使うならFox proでしょうか? だから、あなたが英語の技術文書くらい読めるぞってなら、迷わずFox proだと思う。 英語のMLに入って質問できるくらいなら、世界中にお友達はいっぱいいる。 情報に不足はないはず。 英語が苦手ならdbXL。 昔の勢いは無いみたいだけど、サザンパシフィックの製品は悪くない。(少なくとも昔は) 別にシステム開発しているわけじゃないんでしょう? だったら、桐も検討をお勧めする。 ちょっとしたものをちょこちょこと書くならdBaseよりはるかに簡単だし、 エクセルとの親和性も悪くない。 漢字でプログラムを書くのが最初は違和感があるかもしれないけれど、 エクセルのマクロのように操作手順を覚えこませて、 そのままプログラムの一部とするなんてことが出来てしまう。 お気楽さは最高。 体験版がダウンロードできるから試してみたら? >>165 Prologっていうのは本当に、select * from empwhere job=clearkなどという構文が許されるのですか?信じられない >>188 助言ありがとうございます。 かの昔、DOS時代に桐v3は少しかじりました。そいで、dbaseに移り、DBXLも QuickSilverを駆使して、プログラムしてました。その後、V_dbaseで書き上げたのですが、 日本で終わって、我輩のプログラミングも終了。 今は分析ツールとして使っている次第です。 サザンのARAGOも初期は触っていましたが、今は、、、、です。 一度、桐を体験してみます。FOXproの体験版はないのでしょうか? >>190 > かの昔、DOS時代に桐v3は少しかじりました。そいで、dbaseに移り、DBXLも > QuickSilverを駆使して、プログラムしてました。その後、V_dbaseで書き上げたのですが、 かの昔のさらに昔、CP/Mの時代にdBASEIIを始め、Basicをはるかにしのぐ生産性に感動。 その後、QuickSilverまでは良かった。Windows時代になって、dBASEはもちろんのこと 他のデータベースもさっぱり出てこない。やっと出てきたAccess1.0。なんじゃこりゃ? と思いつつも他に変わるものも無し、しかたなく使い続けて現在に至る。 その他、桐、dBMAGICなどもかなり使いました。 dBASEの良さを知りつつも、あまり戻る気がしないのは、やっぱりSQLの存在が大きい。 大雑把に言ってしまうと、VBAでSQL動かせば大半の処理は済んでしまう。 dBASEのように基本的に1レコードずつ処理するのとはスピードがぜんぜん違う。 入力はフォーム、出力はレポート、途中計算はVBAでSQL文を実行させて処理とすると決めると、 Accessも割と使いやすい。Accessが難しいのは機能が多すぎてしかもダブっていること。 使わないものは思い切って無いものとして割り切ると習得は早いと思う。 > 一度、桐を体験してみます。FOXproの体験版はないのでしょうか? バージョンアップの時期にはたいてい出すようですけど、今はないみたいですね。 >dBASEの良さを知りつつも、あまり戻る気がしないのは、やっぱりSQLの存在が大きい。 ごもっとも!確かにSQLを埋め込んですると、早い早い。(まわりは dbaseで固めてますけど、、、。) >使わないものは思い切って無いものとして割り切ると習得は早いと思う。 未練がましくやっている俺って、、、、。 色々とご助言ありがとうございました。 かなりマイナーでありながら、強烈なdynamic binding機能を有する処理系 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の処理もかなり高速に実行できると思います。 全レコードをいったん読んでしまってメモリ上にキャッシュしてしまえば、 単純な集計処理ならあっという間に終わるでしょう。 クライアントPCのパワーを使うなら、Xbaseの処理系を併用するのも意味が あるので、RDBMSだけに頼らなくてもいい面だってあると思います。 FoxProの海外事例なんかがそうですが、SQL ServerとFoxProデータベースの 併用によりシステムを構築しているものがあります。 Xbaseに未練があってもいいかも。 別に、 SQL鯖+エクセル SQL鯖+アクセス でも割と使えますが? ジジイはawk 若者はRubyかPython 汚ねぇコードでも気にならない奇人はPerl プロ根性のないやつはVB >>165 何故PrologにSQLなんか使う必要があるの? 爺さんはコボル。その見習いの若いのもコボル。 あいつらの頭は進化が止まってる化石。インターネット対応なんて考えが及ばないし。 昔から遣ってる香具師は、ProCとか。最近始めた香具師は、JavaとかPHP。 >>197 RDBとのインターフェイスがSQLである以上、使える方が便利です。 それより データベース言語 = Prolog なのだから >>1 はPrologを否定することからこのスレを始めるべきでした。 プログラムの中でSQL組み立てるのは良くないといつも思ってた。 ストアドプロシージャ使わせてくれないからそうしてたけど。 組みあがったSQL検証するためにデバッグ出力しないといけなかったり。 SQLは集合を扱うことに特化した非手続き型言語とみなせば業務ロジックの殆どはSQLだけで実装できる。 苦手なのはI/O。表現力は貧弱。 だからストアドさえ呼べれば、アウトプットの編集に最適な言語が最適。 WEBならPHP?でもPHPコードが増えるとHTMLの原型留めなくなるしなー 帳票はCOBOL?カンマ編集とか必要になるとスクリプト言語で書きたくなる… すんません。C++使ってます。 プロジェクトはパッケージソフトなんで・・・ >>200 SQL ML Prolog がデータベースを論じるときの基本言語と 昔から決まっている。ML Prolog の限界を語り尽くした後に DBMSとの繋ぎ言語を対象とするべきとわたしも思う。 昔から…ねぇ。 DB特化言語って、命令が色々そろってて便利だけど、何かしら不得手部分が出てくると、そこを何とかするのにえらい苦労させられた思いが強い。 Cでコツコツが、結局は一番な気がする… >>204 ちょっと関係ないかもしれないけど、 WikipediaのPL/SQLを読んでみて、OracleのOCIに 関する言及がまったくないのに驚いた。なにが違うかは 大事なところだと思うが。 いちいちカーソルのオープン/クローズ書かなくて良くて、 SQLの穴埋めするのに何バイト目とかカウントしなくて済むRubyが楽だお。 read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる