前一篇文章簡介 Key-Value Database 的特性，那麼單純的 Key 和 Value 在使用上應該如何設計，才能讓它「好用」？

Key

Key 做為資料的識別碼，如果只為了不重複而使用產生流水號或 UUID 等無意義的值顯然不是個好選擇，因為這會導致程式無法直接從 Key 判斷它所取得對應的 Value 該如何解析。而「有意義的名字」表示開發者需要設計一個命名規則，讓程式可以依規則產出 Key，也因為 Key-Value Database 是使用 Key來取得 Value，Key 的命名必須考慮到取資料的需求。在 Key 中可以包含資料的名字和資料的範圍，搭配不會出現在名字的分隔符號(像是:、-或_)分段，像是 order:20220101:1:cust 表示在 2022/01/01 建立的第一張訂單的客戶資訊。適度的縮寫讓 Key 不要太長，但也不能短到無法識別或造成誤解，像是cnt究竟是content還是count？都是要注意的點。

Value

Value 可以儲存各式各樣的資料，從一個數字到一包複雜結構都可以被放在 Value 中。通常一起使用的資料可以考慮放在一起，像是姓氏和名字在多數情境下都是一起被存取的，比起拆開儲存的設計，

student[std:1:fname] = 'Kei'
student[std:1:lname] = 'Liao'

使用有複雜結構的設計節省存取次數會是比較好的選擇。

student[std:1:name] = '{"first":"Kei","last":"Liao"}'

有時資料在邏輯上互相關聯但不一定經常被一起存取，可以考慮類似反正規劃的作法，在兩邊各存一份相同的資料，像是 name 重複存放在 std:1:name 和 std:1:contect-info 的 Value 中。

student[std:1:name] = '{"first":"Kei","last":"Liao"}'
student[std:1:contect-info] = '{"name":{"first":"Kei","last":"Liao"}, "addr":{"country":"TW","addr1":"...","addr2":"..."}}'

但這樣的設計必須注意資料一致性的問題，例如改名字只改到 std:1:name 卻沒改到 std:1:contect-info 的情況。一般來說 Key-Value Database 對 Value 都有大小限制，過大的 Value 會導致效能下降，如果發現會持續設計出大且複雜的 Value 結構，或許該考慮使用其他的資料庫(像 Document Database 或關聯式資料庫)，而非 Key-Value Database。

Key-Value Database 不像關聯式資料庫對欄位有很強的約束，以上面的 student 為例，它不會要求所有的 student 的 Value 格式都要長得一樣，全看使用者想放什麼資料就可以放什麼資料。這樣的特性很方便，像是對應到程式中物件的多型設計，不用為了不同子類別各自處理 table schema。但既然不由資料庫進行控管，這表示處理多種長相資料的責任落在程式端，會增加程式碼的複雜度，應視需求適度使用。