■
n9dn9d: 「インピーダンスミスマッチ」かー
n9dn9d: うまいなー
kinugim: まーでも、メモつけてるとある程度構造化した情報も扱いたいという要求は無いこともないしな。
kinugim: そう言う用語があるらしいな。
kinugim: 言い得て妙だ。
n9dn9d: うちのシステムインピーダンスミスマッチの嵐だ。（笑
n9dn9d: よんだ！
n9dn9d: ありがとう
n9dn9d: shunsakuもでてた
n9dn9d: わらった
kinugim: まー、なかなか難しい問題だよな。
n9dn9d: うちの場合ある程度正規化されたデータを保存するので
kinugim: おお。
n9dn9d: そんなに難しくないと思うのよ。
kinugim: 喜んでもらえて良かったよ。
n9dn9d: うちの場合 一番問題になるのは null でーたべーすだからな。
kinugim: ま、少なくとも今より上手くはやれると。
n9dn9d: 広大なテーブル中の一部しかデータが入っていない
n9dn9d: まあ、法改正＝フィールド追加
n9dn9d: ってことだから nullテーブルになるのもうなずけるんだが
n9dn9d: 追加されたフィールド、使用しなくなったフィールドがあるはずで
n9dn9d: それの削除を行ってないのよ
n9dn9d: 削除すると後方参照性を失うのだがな。
kinugim: ＸＭＬＤＢみたいな、否定形の情報を扱えるＤＢを使うようになれば、そのへんの面倒なところも自ずと解決すると。
n9dn9d: それぞれの法に従ったスキーマというかDTDを用意するだろ？
n9dn9d: で、X年法に従っているときには任意のDTD内にあるわけだからX年法の範囲ではタグは暴走しないと
n9dn9d: で、過去使っていたタグは 新しい法律のDTDには含まれないのでDTDの肥大化は防げる
n9dn9d: 検索するときにはDTDは関係なので 必要な検索だけ投げればよいし
kinugim: とりあえず、データが知らないうちにメロメロという事態は防げると。
n9dn9d: そいうこと
n9dn9d: DTDの作成者は死ぬと思うが
n9dn9d: 現在の フィールドの暴走よりましだろ？
n9dn9d: 過去のDTDを包含する形でDTDを組まれてしまうと DTDが暴走するがな
n9dn9d: そんときゃ、暴走を認識した時点でDTDを修正すればよい話だろ？
kinugim: だな。
kinugim: でも、ＤＴＤをきっちり管理するってのはキモになるな。
n9dn9d: それってRDBのフィールドと同じなんだけどな
n9dn9d: ポイントは おかしいというかメロメロニなったことを認識したときふぉろーできるかどうかだろ？
n9dn9d: フィールドとタグって「属性名」ということができると思うんだ。
n9dn9d: 任意の情報に対してね
n9dn9d: RDBは属性名の新規追加に対しすべての書類というかレコードへその属性を持たないということを意味するnullを追加しなければならない
n9dn9d: 一方 XMLは属性名の新規追加はDTDの修正で済む。
n9dn9d: これはRDBが属性名とレコードを別々に管理しているためだとおもうんだ。
n9dn9d: ちがうな
n9dn9d: うまく表現できてないな
n9dn9d: ディメンジョンではおなじか
n9dn9d: XMLの場合、任意の属性値が無いときには 記述しないだけか
kinugim: そもそも、データのモデルが違うからなー。
n9dn9d: そこききたい＞モデルの違い
kinugim: ＸＭＬはＲＤＢより複雑なデータ構造も持てるし。
n9dn9d: 包含関係は XML>RDB だろ？
kinugim: 何もウラは無いけど（^^;
n9dn9d: いや、無限の大きさのテーブルが作れると仮定すると
kinugim: データの表現力としては、ＸＭＬ＞ＲＤＢだよな。
n9dn9d: XML=RDBの気がする
kinugim: はは。
kinugim: それって、チューリングマシン＝Pentium4 って言ってるのと同じだ。
n9dn9d: あっ！ 属性値の量か！！
n9dn9d: 属性値の量が多くなっていくと XML>RDB になるな。
n9dn9d: 繰り返し項目とかRDBよわいもんな
n9dn9d: って、そりゃ XMLも繰り返している項目で検索すりゃおなじか
kinugim: んー。
kinugim: 単純な捉え方をすると、
kinugim: ＲＤＢとＸＭＬＤＢは情報の表現方法が違う。
n9dn9d: だな、そりゃそうだ。
kinugim: どういう情報を扱いたいかで、やりやすい方を選べばいいと。
kinugim: もちろんＲＤＢが使いやすい場合ってのも多いだろうしな。
n9dn9d: って、あまりないんだよな。
kinugim: 具体例に当てはめて考えるのがいいような気がする。
n9dn9d: RDBが基礎データってことはあんまりないぞ？
n9dn9d: RDBってもともと 計算を高速にするために生まれただけか？
n9dn9d: ちがうな、人間にとってデータの保持形態が理解されやすいように開発されたはずだ。
n9dn9d: テーブルを眺めれば保持データが概視できるってメリットをもってる
n9dn9d: 一方 XMLDBのほうは 保持データの概視は検索してみなきゃわからない
n9dn9d: 単件データの場合はXMLの方が優位か。
n9dn9d: ま、いいか、XMLDBがリアルタイムで動けばそれで問題なしだよな？
kinugim: ううむ。
kinugim: だとおもう。
kinugim: http://www.intelligententerprise.com/db_area/archives/1998/9810/feat4.jhtml?_requestid=21126
kinugim: そもそも、ＲＤＢってのは関係演算の計算モデルを実際にインプリメントしたものなのかな。
kinugim: ＸＭＬはここのデータをどう表現するかに重点が置かれてる気がする。
n9dn9d: うぇ・・・えいごじゃん
kinugim: 難しいな。
kinugim: 探せば日本語の解説サイトもあるんじゃないかな。
