今日はCouchDBの話というよりも、key-valueという形に基づいてのデータ構造設計を考えてみたときの与太話です。 DOA自体の説明はここでは端折ります(ERDレッスンをお読みくださいm(__)m)が、その考え方の中で非常に重要でありながらも実現に際して途轍もなく困難なものがあります。それがデータディクショナリです。 データディクショナリ(以下DD)とは、乱暴に要約するとシステム内で登場する全てのデータ項目に対して意味合い・意図をしっかりと定義して辞書のように統合し、利用者の間でぶれのない状態にしましょうというものです。そしてDDの作成においては、エリアス・ホモニム・シノニムの除去が重要になります。ホモニム・シノニムについてはhttp://www.atmarkit.co.jp/fbiz/cinvest/opinion/qa/qa13_2.htmlをご覧ください。ちなみにエリアスは別名
またまたCouchDB絡みの話です。key-valueストアでスキーマフリーなデータベースを前提にすると、DB設計の考え方が大きく変わってくるのを感じます。 得意先でもあり仕入先でもあるという場合、上位の抽象クラスとして取引先を作ってそれを継承するという形になるのが一般的だと思います。ところがこれがスキーマフリーのパラダイムになると「タグでいいじゃん」ということになる。 例えば得意先でもあり仕入先でもあるというような場合、取引先という抽象エンティティを置いてそれを継承・派生させる形でモデルを作ります。これはERモデリングだとサブセット、OOだとサブクラスと呼ばれます。しかしスキーマレスにはそもそもそんな区別がありません。タイプという名前で属性をひとつ作ってしまって、そこに「"得意先", "仕入先"」という値を入れればいいだけです。 クラスなり集合なりというのを考えるに際しての一番のポイント
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く