アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
全てが表だと困っちゃう (スコア:1)
それでもRDBってものには複雑な(おいそれと賛美できない)気持ちを持たずにはいられないです俺。
なまじ表構造なもんだから、表と相性が良いとは限らないTreeだのNetworkだのの様々な構造を
取り得るデータ…最近の流行だとObjectですが…との間で、いわゆる
意味的インピーダンスミスマッチを、抱えさせられるんですよね。アプリ作ってると。これが辛い。
というわけでRDBもほどほどにしてOODBなりなんなりの時代になって欲しいなあ。
ええと。俺の理解が間違ってなければ(笑)、細か
RDBじゃないと恐ろしい (スコア:0)
表にできないところはそのままBLOBにブチ込んであとで展開したり、データ構造自体が表に出来ない場合はそこだけオンメモリにしたりして、主なところだけを表にするようにしないとダメ。じゃなければ物理デバイス自体を改良しないと。
新生代のデータベースなりデータ構造なりというものは、モデルに対してこれまたある種の「制限」を課すことによって生まれるんじゃないかな。なんで
Re:RDBじゃないと恐ろしい (スコア:1)
>データ構造自体が表に出来ない場合はそこだけオンメモリにしたりして、
>主なところだけを表にするようにしないとダメ。
そんな無茶な…
オンメモリにしちゃえってのは、そこを永続化するために別の工夫が要るってことですか?
なんか、何もするなといわれてるような気がしてならないなあ。
>じゃなければ物理デバイス自体を改良しないと。
「物理」まで手を出す必要あるんですかね?
それって(DBのデータ塊を置く場所である)ファイルそのものが
RDBには向いているけど他のDBには向いていない、と
言ってるようなもんだと思いますが、そこまで言えるもんなんでしたっけ?
#むしろRDBのデータファイルが古典的な「ファイル」に(効率よく)収まることのほうが俺には不可思議なんですが…
>新生代のデータベースなりデータ構造なりというものは、モデルに対してこれまたある種の「制限」を課すことによって生まれるんじゃないかな。
それは勘弁願いたいな。ODBが先祖がえりに過ぎないロクでもないものだってのは確かに言えます(笑)が、
だからって逆に、進化の方向が常に制限で縛られて使いにくい方向にしか向かない、なんていう真っ暗な未来も
ちょっと想像したくないです。
せっかくプログラミングが昔に比べてこれだけ楽になったというのに、
それを永続化しようとしたとたんに地獄っすか?
それは人としてどうよ?という感じ。
余談:
そんなことするくらいなら、人はもっと違う世界に逃げようとするんじゃないかな。
例えばSmalltalkみたいに(笑)とりあえずメモリ上のObjectを全部そのままファイルに書くだけの世界。
それじゃ困るという声が生じそうですが、サーバーサイドなんかは特に、「ファイルに」落とす必要が
どれだけあるかってのを再考したほうがいいんじゃないかなと思います。
つまりshutdownするまではオンメモリでやっちゃえと。
そうすりゃついでにOOP言語でサーバーサイドロジックも素直に(ローコストで)書けますしね。
OSはワンレベルストアを提供してくれりゃそれでいいかも。ん?物理的って、このことですかね?
>なんでもありの OO からはおそらく何も生まれない。RDB もデータ構造を大胆にむりやり表にして相互に関係づけさせることで生まれたわけで、
OOは何でも有りってほど何でも有りではないですけどね(^^;。
#「このくらいいいじゃん!」という感じかな(笑)
ただ、こないだも書いたけど、OOとRDBのマッピングについても、素朴な1クラス1テーブルとは
全然違うヤリカタにすると、それはそれで面白い世界が拓けてくるんじゃないかとも思うので。
余談:
あのPRbの説明を読むとむしろ、OOPも
「データ構造をむりやりObjectと参照(属性名)の連鎖にして相互に関連づけさせる(Binding)ことで生まれた」
などと言えるような気がします。
その軸は、いわゆるユーザーのモデリングの恣意性とは無縁の世界なんで。
>エンジニアが自分の直感でシステムのデザインを決めるような時代は絶対に来ないし来ても意味がない。
「来ない」というのが何を指しているのかちょっと不明なんですけど。
なにせ、今がまさにその「直感で決めてる」時代なのですから、もう「来ています」ですよ?(^^;
良し悪しはさておき。