アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
全てが表だと困っちゃう (スコア:1)
それでもRDBってものには複雑な(おいそれと賛美できない)気持ちを持たずにはいられないです俺。
なまじ表構造なもんだから、表と相性が良いとは限らないTreeだのNetworkだのの様々な構造を
取り得るデータ…最近の流行だとObjectですが…との間で、いわゆる
意味的インピーダンスミスマッチを、抱えさせられるんですよね。アプリ作ってると。これが辛い。
というわけでRDBもほどほどにしてOODBなりなんなりの時代になって欲しいなあ。
ええと。俺の理解が間違ってなければ(笑)、細か
Re:全てが表だと困っちゃう (スコア:0)
プログラムの性質に合わせて変えたらいいのでは。
別にRDBにこだわる必要もない。
Re:全てが表だと困っちゃう (スコア:1)
だけど実際には、サポートやらネームバリューやらのせいで先にRDB(主にoracle)に決定するケースが多いんですよね。
OODBに特化した製品もあるのに推進するだけの(材料||件名)にならないという(汗
(oracleのOODBに関する動きだとoo4oをwrapするくらい?識者の意見を求む)
私の場合は、某F社のメインフレーム上での開発がメインだった時期があるのですが、当時のNDBの方が今のRDBよりもoopsにフィットする気がしますね。
---- 何ぃ!ザシャー
Re:全てが表だと困っちゃう (スコア:0)
GETANY GETNEXT GETNEXT...あぁBANK ACEが懐かしい.
Re:全てが表だと困っちゃう (スコア:1)
選択肢が有ればいいんですがね(^^;。
Transactionがきちんと有って、しかも普通の奴らの上を行ってない(そのせいで選択してもらえる(笑))ような
DBとなると、やっぱり今はRDBが多いでしょうね。
同様にObject指向言語に拘る必要もないわけなんだが、いまどき使い物になって、しかも普通の(中略)
言語となると、OOP言語が多いかな。
ところでプログラムの性質といっても、Collection(OOP言語風に言えば)の能力で大勢が決するって面が有りますね(^^;
まあGreenspun's Tenth Rule of Programming [dreamhost.com]ということだそうで。