株式会社マジカジャパンの羽生章洋が書いてるブログ:今日のCouchDB - livedoor Blog（ブログ）

テクノロジーカテゴリーの変更を依頼記事元:

blog.livedoor.jp/habuakihiro

32 usersがブックマークコメント

記事へのコメント8件

注目コメント
新着コメント

ita-wasa でも、この明細の扱いをクリアしたことで、私の中ではこれまでRDBMS使ってきて感じていた「う～ん」という気分に対して、相当に良い感じで解決策を見いだせそうな気がしています。CouchDBに関するドキュメントでスキーマ

2009/05/16 リンク

aufheben 型とか言ってる時点できっと駄目なんですよ … そっ、そうなんですか?

DB
CouchDB

2009/05/16 リンク

yamadamn key-value型DBでの、ヘッダ-明細の扱い

database

2009/05/14 リンク

gothedistance 勉強になる。

2009/05/14 リンク

nak2k 子インスタンスが親インスタンスに対して局所的な時に性能面からも特に気になる部分。>リレーションシップの設定で嫌われる、あるいは胡散臭く感じられるのは、正にこの部分

2009/05/14 リンク

yssk22 Viewに対するViewがほしい！というのはMLでも流れてますね => CouchApp を使えばそれなりに解決できますね || 賛成!! < 21世紀のネオDOA宣言！

couchdb

2009/05/14 リンク

bash0C7 "興味を持つ人もあんまりいない"興味津々|オンラインAPの場合"何件あるか不明だけど、とにかく全部放り込む"時は都度DBを読んだ|RDB以前の階層型DBの知識が要るなあ

development

2009/05/14 リンク

yohei CouchRestも勝手に作るけどtypeはいらない気がするんだよなあ。期待した構造のdetailsというプロパティがあったら、よしなに処理しちゃう方が、たぶん僕が想定しているアプリには合うんだろうな。

couchdb

2009/05/14 リンク

注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

規約違反を報告

株式会社マジカジャパンの羽生章洋が書いてるブログ:今日のCouchDB - livedoor Blog（ブログ）

メインフレーム時代とはCOBOL時代と言い換えてもいいでしょう︵RPGやPL/Iの方には申し訳ない︶。これは... メインフレーム時代とはCOBOL時代と言い換えてもいいでしょう︵RPGやPL/Iの方には申し訳ない︶。これは更に言い換えると固定長のパラダイムだとも言えます。オープンシステム時代になりRDBMSが主流となったときに一番のパラダイムシフトは、実は明細の扱い方だったと言えます。 COBOLをご存じの方はOCCURSを当然使っていたはずです。OCCURSとは繰り返しを表すもので、売上データというファイルがあったときに明細部分は繰り返しになりますから、OCCURSを指定します。ややこしい言い回しを使っていますが、要するに配列定義ということです。さて、COBOLは固定長のパラダイムだと書きました。実はこのOCCURSで定義される配列は繰り返し数が事前に固定されます。例えばOCCURS 5.と書けば5回繰り返しということです。一応可変長が可能ということになってはいるのですが、多分今でも指定した上限を