一套商業業務的需求，以CASSANDRA/SCYLLA的設計理念，資料模型要怎麼開，與RDBMS的不同之處，想必大家或多或少也有些概念了。

因為在開keyspace、table之前，就需要先想好查詢方式。

而CASSANDRA/SCYLLA的查詢限制，與資料的運作方式，又必須要先明白其中概念。

所以筆者認為這樣的攻略方式，才是因循漸近，才是符合真正想要好好使用這套工具，應用到實際開發層面的必要前置作業。

開始設計時，要分離一直以來既有的RDMS使用概念，我們重點整理條列出來：

1. 沒有join

沒有辦法在查詢時，再組裝不同table的資料，於是每個查詢目的，開出來的table應該都要有辦法滿足。

例如需求上，需要查詢個人完整資料，譬如說個人的學歷，經歷，身體健康狀況細節等，應該在一張table能夠滿足查詢，而非學歷資料放一張table，經歷資料放一張table，身體健康狀況細節又放在另一張table。

2. 反正規化

承沒有join的機制，當然也不會有正規化，所有的設計都是反正規化，如果覺得寫入太多張table都是相同的資料，考慮重新檢視一下資料結構，是不是應該收攏在同一張table，查詢條件可以MATERIALIZED VIEW的方式輔助。

在分散式NoSQL DB，並不怕一張表塞太多資料，顯得太臃腫，而是怕primary key，index key沒有設好，查詢的時間就會變得無法評估。

3. 沒有參照完整性(referential integrity)

簡單地以RDBMS來說，就是沒有foreign key那種東西，因為根本上就沒有join的機制，table之間的資料關係，並沒有那種交集的概念。

4. 先想好查詢情境，再設計資料模型

這可能是從RDBMS，最難轉換過來的一點，換句話說在實務的開發工作上，會是先進行盤點查詢資料的情境和用途，商業業務與功能之間的關係，這些部分都有個規劃之後，才建立資料模型。

有人認為用查詢條件去設計DB會導致許多限制，CASSANDRA/SCYLLA對此的理念是，查詢情境本來就有可能隨著需求而改變，因查詢情境不同而去調整資料結構模型，這點本質上在RDBMS也會遇到，實務上RDBMS並非資料模型開完之後，就可以藉由各種關聯式查詢永遠滿足各種查詢需求，遇到缺少的，不能滿足的，還是得要調整結構。

5. 資料排序方式，在設計階段就要決定好

在系列的Day13. 排序有介紹，CASSANDRA/SCYLLA起因於結構限制，在設定primary key的時候就要決定好排序方式。

這個部分對於很習慣RDBMS的人，也是一個很難克服的點。

再者，筆者工作以來的經驗，很多排序上的需求都是專案晚期，或者第二階段的報表需求才會用到，要在專案一開始就把這類需求盤點好，似乎不太可能。

筆者的工作環境，針對這部分的功能，大部分都還是RDBMS那邊的資料做提供，不過也有可能是我們團隊使用SCYLLA的經歷還算年輕，或者需求上就剛好沒碰到。