把每一筆資料都當成一個物件吧 !
例如
基本正常人
{"name" : "Andy", "age" : 26, "gender" : "male"}
已婚人
{"name: : "新垣結衣", "age" : 31, "gender" : "female", "marry" : "Y"}
結衣鐵粉
{"name: : "dragonH", "age" : 31, "gender" : "male", "hate" : "星野源"}
原則上這三種人都存在 person 這個集合 (collection)
不過並未強制要求 未婚者 一定要有 婚姻狀態(marry)的屬性
當然也非每個人都是 結衣鐵粉 , 所以也不一定要有 討厭東西(hate)屬性
即便有, 只有 hate 為 星野源 才算 結衣鐵粉
不過要找出已婚人就需要去集合 婚姻狀態(marry) 為 Y 的所有人 ,
同理如果要找出結衣鐵粉則是集合 討厭東西(hate) 為 星野源 的所有人 
因此 NoSQL對於每個屬性質 (ex: gender, name, age, ...) 的掌控, 背後的
意義必須非常清楚 !
處理上, 坦白說, 有點像是生物學的 : 種屬科目綱門界 的區分過程
相較於關聯資料庫, 曾經見過欄位是 col_1, col_2...
不過還是運作好好的系統 ! 因為資料表名稱已經幫你預先分類了 !
感覺有點似懂非懂，
那婚姻狀態集合內的資料該長怎樣呢?
原本的物件照摳嗎?還是有另外的屬性設計?
{"name" : "新垣結衣", "age" : 31, "gender" : "female", "marry" : "Y"}
抱歉我被PK,FK影響太深了
沒有特別限定, 例如
{"name: : "周董", "age" : 40, "gender" : "male", "marry" : "Y", "car" : "蝙蝠車", "wife" : "昆凌"}
只要 marry 是 Y 就已婚 !
畢竟 Andy, 新垣結衣, dragonH, 周董, ... 都是獨立的個人(物件), 本來就有獨立的區別特徵 !
只是你在檢索時, 需要那些特徵是可以被明顯區分的 !
例如全世界的蝙蝠車是限量發行 ! 如果有一個全世界人的NoSQL資料庫,
你檢索蝙蝠車就能比較快找到周董, 當然也可以直接檢索 wife 是 昆凌 啦 !
對於 NoSQL 的物件設計建議採繼承方式來建構
例如: 新垣結衣 一定繼承 女性
{"name" : "新垣結衣", "gender" : "female"}
只是她還可以告訴大家已婚, 因此也繼承已婚
{"name" : "新垣結衣", "gender" : "female", "marry" : "Y"}
不過卻不對外公布她的 husband
所以在設計 NoSQL 的過程, 真的滿像在處理生物學上的 種屬科目綱門界 的過程 !
感謝 darwin0616 大大細心解釋
後來我有找到一篇比較詳細的說明了
6 Rules of Thumb for MongoDB Schema Design: Part 1
媽我上電視了 
這些也可以參考
MongoDB Schema 設計指南 (Part II) - 反正規化的威力
突然發現這兩篇也是作者參考 6 Rules of Thumb for MongoDB Schema Design 寫的
貼個 MongodB 資料集轉成 資料表 的實際情形給大家參考：
有幾筆連 null 值都沒有...
然後我個人是習慣用 Robo 3T這套來控管 ＭongodB
然後我個人是習慣用 Robo 3T這套來控管 ＭongodB
我也是用這個
不過他中文輸入在 windows 好像有問題
不知道是不是只是個案
iThome鐵人賽
看影片追技術