データベースプログラミングに最適な言語は何か
データベースプログラミングに最適な言語は何かを論じたい。 まず、漏れは Ruby を推したい。 内部イテレータのおかげで、短いコードでデータの取得、メモリの解放が可能だ。 Perl や PHP はオブジェクト指向の機能が不足である。Javaやは型宣言を せねばならず、ムダにコードが長くなる。保守性は悪くなる。 つまり、Javaは別の分野で用いるべきである。 .NETやPythonは知らないが、.NETはJavaの片割れでたいしたメリット無いみたいだし、 PythonはRubyのライバルとされているが、どうか。イテレータの書きやすさは Ruby のほうがいいな。 >>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が楽だお。 >>208 人間、楽をするとろくなことがないよ。 目先の労力のことではなく、 人間性の形成の話だけどな。 苦労を厭わず飛び込んでいく香具師のみが 人として幸せになれる。 >>209 私も昔はそのように思っていましたが、 ただ自分の仕事が増えただけで、幸せにはなれませんでした。 常に楽が出来るように考えたほうが、人として幸せになれる。 怠惰 短気 傲慢 がプログラマーの三大美徳。 楽しようとしない香具師は向いてないだろ。この仕事。 >>210 何言ってんの。 自分の仕事が増えるってことは 他人より信頼されて任されてるってことでしょ。 プロとしてこれほど名誉なことはないじゃない。 仕事なんて、気の持ちよう一つで 天国にも地獄にもなるよ。 >>211 楽しようとして苦労するんだけどな (w 楽しようとして苦労するのは良く有る事。まあ、良い事だろう。 楽ばかりして、コードを書く量が減るのはダメでしょ。 なんで? やりたいことができるなら、コードなんか少ない方がいいと思うぞ。 (スパゲッティになるとか、perl の呪文みたいな無理矢理圧縮は別にして。) PrologによるSQLまがい。所詮はまがい・・・ 昨日入力数(_部署,_入力数) :- 部署(_部署), 昨日(_昨日), 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文の パターンを引き出す。ただし、このライブラリは最近手を 付けたばかりで未完成です。 関西支店でなくて関西支社ねww.. Prologは(中)小企業向きで あることを暗示したいのですね。 やっぱりCが無難かな。 DB以外の要求機能のほうが重要だったりするし。 javaで書くよ。 どうせ、networkとかIOが足引っ張るし。 なにより、スレッドの同期とか楽なんだもん。 C+pthreadよりは間違いなく楽。 java.util.concurrent使えるなら、もっといい。 >>219 DBMSを書くためということですか? それとも DBMSの中のアプリ(例えばSQL+)を書くためということですか? といあえずJDBC使うと後でDBMSの移行が楽になると思うぞ。 ホント Pro*Cからecpgへの移行は地獄だぜ! フゥハハハーハァー わざと移行させたくないし、ソースも提供したくないから、ProCで作って納品している。 プレゼンで見せる時はphpだけどな(w jdbcも結局は独自発行コマンドを駆使するから、簡単にはDBは変えられない。 コードかくの面倒だから GUIで画面構成とかプロパティがんがん決めれて、 RowSourceにSQLつっこめばレコード返してくれる ACCESS+SQL Serverが一番楽な気がするのですが、 これより楽なのありますか? 中小企業の商品在庫管理と、大規模なシステムと Webサービスでは求められる物も答えも違うだろ。 どの場合においてもRubyじゃ無いことだけは確かだが。 Windowsなら、IronRuby、IronPythonが面白いと思う。 >>227 ADO.NETつかうなら、どれもあんまり変わらない気がする。 SuperCon2007 ― 夏の電脳甲子園 http://pc11.2ch.net/test/read.cgi/tech/1181916316/ 1 :デフォルトの名無しさん :2007/06/15(金) 23:05:16 がんばれっ!天才高校生諸君 スーパーコンピューティング・コンテストSuperConは、 高校生がスーパーコンピューターを使って、プログラミングのアイデアを競う大会です 今年は阪大に今年導入された最新のスーパーコンピューターを使います プログラミング大好きな高校生諸君! 来たれ阪大・東工大へ!! 諸君のアイデアをスーパーコンピュータ上で実現してみよう!!! http://www.gsic.titech.ac.jp/supercon/supercon2007/index.html たしかにDelphiは良かったな。過去形だけど・・・ rubyってコマンドラインで使えるんだっけ? バッチ処理とかそこだけperlとかで書くのかな。 Javaいいけど、サーブレットにすると更新するたびに再起動とかサービス止まるじゃん。 大手ポータルやSNSが採用してる perlかPHPじゃねーの 個人的にはCで良いよ。 パフォーマンスで劣ることはないし 出来ないことはないし スクリプトだなんだと言うならobjectCにしる。 でもやっぱり文字列処理とメンテナンス性とったら PHPかな。 >>237 なんすかその人工無能が書いたような文は マジレスすると もう4th Dimensionしかねぇな。 他のDBじゃ目が回っちまうぜ ActiveRecordは後からデータベースの種類を切り替えられるけど、 ADOはどうなんですか?Connectorだけ切り替えればいけるのかな? このスレ生存していたか。既出かもしれないけど、 Prologをオンメモリデータベースとして強化すれば、 それだけでいいんじゃないの。 俺はジジイだからbash・awk・sed・grepの組み合わせ。 perlやpythonも齧ったんだが、馴染めなくてな。 ピッチピーとオラクルでよいレベルからはいあがれません >>248 成分分解法によるデータ管理とPrologを結合したら面白そうだね。XMLやExcelじゃ、ちょっとね。 PowerBuilderのDataWindowがすごく使いやすい。 10年以上PowerBuilder使い続けてるよ。 Access, Delphi以上に楽なツールなんてあるのか 最近 C# ちょっと触る機械があったんだが、 IDE も賢くなってるし、膨大なライブラリが あるので結構楽だったよ。 ただ現状ではまだ配布が面倒なので自分用の ツールにしか使ってないけど。 俺も最近は C#(.NET) だな。 たぶんこう使うんだろう、 でそのまま使えて驚きですわ。 >>252 うわぁぁぁ、それって今は亡きボーランドのDB専用プログラミングパッケージだったけ? 大昔にパラドックスっていうRDB買ったせいか、チラシ送ってきたっけ。 Grails Object Relational Mapping (GORM) http://grails.org/GORM だれも知らないだろうがunifaceだよ。 こいつの生産性はメチャクチャ高い。 ただし、価格がこれまたメチャクチャ高い。 >>266 なぜか日本ではSYBASEで売ってないw いまだにストアドプロシージャが銀の弾だと主張してるアホ発見 生島勘富とかいう奴 俺がいままでDBアプリを作ったことがある環境は ・VB6+ODBC ・C#+SQLite.net ・PHP+Pear::DB ・CakePHP この中じゃCakePHPが圧倒的に楽だったよ。 >>1 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 ?- >>271 上側の一般的なProlog照会と下側のデータベースシステムに対する照会が構文的に まったく同一でいけるという意だと思うが、 Prologの単位節データベースの引数に id1:'023449' のような構造体(:がfunctor)を 持つことは、単一化の総コストが大きくなりすぎて、現実的(実用的)ではないのではないか。 >>271 現在のPrologの仕様では ・ 節の順序を変更することのないupdateが難しい。 ・ 数十万を越えるような連続したassertが想像以上に時間がかかる。 >>271 それと、 下のPrologの副目標として、データベースシステムを参照にいく場合とは、 元々Prologの述語としてデータベースがあり、 そのコードをデータベースシステムの照会にそのまま借用したいということだろう。 この場合通常、Prologの副目標は最初にテーブルの参照があって、その後に 単一化された引数の検査という順序で書かれている。一方、このコードをSQL文字列に 変換するとなると、sql文を発行する時点で、where句の条件を知っていないと効率の 良い照会にはならない。 つまり、テーブルの参照は遅延しておいて、その後の副目標群の解析を先に進める必要が ある。そのためには、どこまで解析すればよいのかを示す何かが必要になり、多くの場合、 ブロック構造が導入されることになる。 この時点で少なくとも>>271 のコードそのものではなくなる。 >>274 ブロック構造で翻訳を指示したとしても、 SQL参照と無関係な副目標が存在することも多く、編集を 余儀なくされるというケースはあります。 それから現在のエジンバラ版(Dec10)のPrologではカンマが特権的な位置を占めてしまっていて、 オペレータ定義を駆使しても、 select id,data from foo というような表現できません。 select (id,data) from foo ならOKですが、これだとSQLの方で構文エラーになります。 本当にデータベースシステムと双方向に一体化するためには エジンバラ版Prologを放棄した方がよいと思います。 >>276 連接を表すオペレータを"&&"に変えてみる ?- member(_組,['A','B']) && select 学年,組,名前,性別,生年月日,住所,電話番号 from 学籍簿 where 組=_組 and substr(住所,1,3)=東京都. これだけでよいのかな。 >>277 属性名と属性値を区別するオペレータが必要になる。 暗黙的な解釈としては、式の左項は属性名、右項は属性名でよいが、 結合の時に、共に属性名であることを明示しなくてはならない。 それから、現在の仕様では、 t1.氏名 = t2.氏名 の t1.氏名 がsyntax errorになる 処理系もありそう。本来は t1.f1 = [t1|f1] となってエラーにはならないはずだが。 >>277 それだと、組が'A'の場合しか表示されない。 やはり、最後に && fail. が必要。 データベースに最適な言語がPrologです。これでは当たり前過ぎて、 面白くない。もともと、それに特化した言語だからね。 このスレタイでも、Rubyがあがっているように、もう少し捻った 議論はないものか。 データベースを作るのに最適な言語は? ということになると、やはりCかな。 昔はデータベースアプリと言ったらdelphiと言われてなぁ。。。 楽天やアマゾンの商品リストのデータベースってどうやって取得するの?誰か教えて read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる