「RDBMSの生みの親Edger F. Codd博士、死去」記事へのコメント

全てが表だと困っちゃう

[G7 (3009)]

氏の仕事が、押しも押されぬ重要かつキッチリした仕事であることは、疑いようもないんだけど、
それでもRDBってものには複雑な(おいそれと賛美できない)気持ちを持たずにはいられないです俺。

なまじ表構造なもんだから、表と相性が良いとは限らないTreeだのNetworkだのの様々な構造を
取り得るデータ…最近の流行だとObjectですが…との間で、いわゆる
意味的インピーダンスミスマッチを、抱えさせられるんですよね。アプリ作ってると。これが辛い。

というわけでRDBもほどほどにしてOODBなりなんなりの時代になって欲しいなあ。

ええと。俺の理解が間違ってなければ(笑)、細か

Re:全てが表だと困っちゃう

[saitoh (10803)]

RDBには世話になっているが、恨みも多い。 業務ソフトで、「バックエンドにRDBを使うので 別途ORACLEを買ってください」っていうやつ。 予算を喰う喰う。
八つ当たりですが

Re:全てが表だと困っちゃう

[Anonymous Coward]

オマエは本当に Oracle が必要なのかと、
ただ Oracle とか言って気取ってみたいだけちゃうんかと、
小一時間問い詰めたくなるわけで。

前に当たった小規模 SIer は抱えている SE が Oracle しか分からないため Oracle で提案してきやがりました。同時接続数 15 以下、

Re:全てが表だと困っちゃう

[Anonymous Coward]

>前に当たった小規模 SIer は抱えている SE が Oracle しか分からない

Oracleじゃないと満足しない客もいますからねぇ
そういう客が存在する限りOracleさえ使えるようになれば、なんとかなるんじゃねぇか、、という考え方のSEが育つのも当然か、と思います

/*
そういう客に限ってtns

PL/SQL(オフトピ)

[cooper (4658)]

いいですよね、PL/SQL。メソッドのオーバーロードをサポートしてたりするし。あとは DBMS_* なパッケージとか、カーソルが簡単に使えるとか、拡張性があるとか、例外処理が楽に書けるとか、パフォーマンスがいいとか。

個人的には、Oracle というより、PL/SQL が使えるかどうかで設計が全然違ってきちゃいますね。開発も楽になるし、メンテ時

--

-- cooper

Re:PL/SQL(オフトピ)

[G7 (3009)]

PL/SQLの有り難味って、言語仕様がどうこうじゃなく、サーバーサイド(しかもDBエンジン内)で動く言語処理系だから嬉しい、
という感じですよね。言語仕様そのものはあんまり格好良い言語ってわけでもないような気がする。

あれ？Oracleのサーバー側

Re:PL/SQL(オフトピ)

[cooper (4658)]

Javaのほうが言語としては数段便利だろうなとは思います。はい。

確かに、言語としての利便性とか快適性は Java のほうが断然上だと思います。ただ、データベースとの「距離感」という意味では、PL/SQL のほうが近いかなぁと。近いからいい、というわけではなくて、要は使い分ければいいだけなんですが。

やっぱり、Java Stored Procedure だと、なにかこう奥歯に物が挟まったような気持ちになるんですよね、うまく表現できないんですけれど...

そこらへんについてちょっと書いてあるコラムはこちら：
http://otn.oracle.com/oramag/oracle/03-jan/o13java.html

--

-- cooper

Re:PL/SQL(オフトピ)

[G7 (3009)]

今日は(?)英語がさらっと読めるほど奥歯の調子がよくはないので、Java Stored Procedureで色々ググってみました。

うーん。なんだろうこれは？
面倒さは、どっちかってーと、周辺のツール(の整備度?)とか言語仕様とかが面倒さを醸し出しているような気がしました。
プログラムをサーバーに突っ込む手順がもっと楽になればだいぶ良い感じになるんじゃないかなあ？

Classのソースを全部自分で書かないとならないのだとしたらウザイから、
該当Methodの中身のコードだけ書いたら、その外枠は勝手に生成してくれる、というツールが
あればいいんだろうな、という感じかなと。

あと、Javaだとクドイというかなんというか、な面はあるかも知れません。
それこそRubyみたいな軽いノリの言語のほうが更に嬉しいかもと思う。