2014-03-06

http://anond.hatelabo.jp/20140306115841

多対多のデータは確かに冗長になりそうだし、処理するためのコードも長くなりそう。

RDBはその点、データ原子性は保たれるし、SQL比較的短く書けるので品質も問題が出にくい。

でも、そうしたデメリットをさっ引いても、技術者要求レベルが低く済むメリットはあると思ったので。

記事への反応 -
  • ファイルシステムのディレクトリのような木構造にデータを格納するのは、RDBに比べたらデータ構造が人間には超分かりやすいし、検索にかかる時間も簡単に見積もれるし、そもそも高...

    • 使った事無いけど、階層で多対多とかやろうとすると、データが冗長になるんじゃないの? データの整合性をプログラムロジックでとろうとするとバグが入りやすいのが問題じゃない?

      • 多対多のデータは確かに冗長になりそうだし、処理するためのコードも長くなりそう。 RDBはその点、データの原子性は保たれるし、SQLで比較的短く書けるので品質も問題が出にくい。 で...

    • RDBとXMLDBですかね。 どっちが良いという話ではなく。

      • XMLDBもだけど、階層型DBが昔メインフレームではCOBOLとセットでよく使われていたと聞いたので、オープン系で使われないのが不思議というか。

        • たぶん元増田の疑問というかニーズみたいなものはこんな感じかね。 ・RDBでも良いから程ほどにゆるくやりたい → Sqlite ・データ構造に柔軟性を!変化を! → XMLDB ・整合性には目をつ...

          • ・データ構造に柔軟性を!変化を! → XMLDB ここに、ドキュメント指向のMongoDBとかCouchDB系が入ってきてる。 データ構造/表現が最近のプログラミング言語のハッシュマップ(or 連想配列 ...

            • おー、あるんだ。良かったな元増田。 というか俺も勉強になった。 ありがとう!

            • 元増田です。 なるほど、そういうDBがあるのか。 XML的なデータ構造をJSONで記述し、プロセス間通信等で使えば実装が楽なのは経験済みだし、ハッシュもちょっとしたデータ構造の構築・...

記事への反応(ブックマークコメント)

ログイン ユーザー登録
ようこそ ゲスト さん