key-valueはデータディクショナリの夢を見るかの自分的解
色々悩んでたらblog的日付が更新されてしまった。寝なきゃ。
habuさんのblogにちょっかい出すのは初めてだな。
ですが、同じ呼び名を場合ごとに見分けるとなると、見分けるための区分なりが必要です。つまり境界が不可欠ということになります。そこでRDBMSを基底として考えられてきたDOAでは、テーブルやエンティティという考え方が所謂ネームスペースとして機能してきたわけです。つまり商品エンティティの中にある価格は所謂標準価格を意味していて（だったら標準価格とちゃんと名前をつけたいのだけど何故か大反対に遭うｗ）、契約エンティティの中の単価というのは契約価格（いやそこ単価いうてるのに価格て）として扱う、などです。ここに各画面ごとにレイアウトの都合などで短縮名でラベルに記載するとかすると、これがもう何かあったときに泣けるわけです。
(略)
実際にはJavaScriptなりなんなり（PythonとかPythonとかPythonとか）で所謂if文を書くことになるのですが、要するにいきなり剥き出しで項目名（つまりkey）を狙うことになります。
このときに上述したようなホモニムやシノニムなどがあるとどうなるでしょうか。つまり同じkeyなのに意味合いが違うものがあったり、違うkeyなのに同じものとして扱わないといけないのです。
http://blog.livedoor.jp/habuakihiro/archives/65222302.html
そもそもJSONなので、フラット構造のみならず階層構造も可能なわけで、それが所謂ネームスペースの役割を果たせると思ってます。
{ "ID":"〜", "名称":"〜", "仕入れ":{ "単価":100, "顧客ID":"〜", }, "在庫":{ "単価":130, "数量":345, }, }
そうすると、「value.仕入れ.単価」と「value.在庫.単価」と区別できるわけで。*1
ただ、意思疎通の武器として、保守しやすくするための道具として辞書は必要だと思いますが。
あとネームスペースを分ける方法としてはデータベースを分けてしまうというのも一つの手。トランザクションがどうなるのかとかはまだ試してませんけど。*2
まぁ何にせよ、世の中「こうあるべき」だけでは動かないのが客商売。
