多年來，我一直在處理這個請求，它給了我們這樣的回應（這是一個很多欄位被切斷的簡短示例）：
{
"catalog": {
"categories": [
{
"id": "firstCategory",
"name": "The first category!",
"order": 0,
"offers": [
{
"id": "offer1" // a LOT of fields
},
{
"id": "offer2" // a LOT of fields
},
{
"id": "offer3" // a LOT of fields
}
]
},
{
"id": "secondCategory",
"name": "The second category!",
"order": 0,
"offers": [
{
"id": "offer2" // a LOT of fields ... same again
},
{
"id": "offer3" // a LOT of fields ... same again
},
{
"id": "offer4" // a LOT of fields
}
]
},
{
"id": "thirdCategory",
"name": "The third category!",
"order": 0,
"offers": [
{
"id": "offer1" // a LOT of fields ... same again
},
{
"id": "offer4" // a LOT of fields ... same again
},
{
"id": "offer5" // a LOT of fields
}
]
}
]
}
}
您怎么看，我們有一定數量的類別（在我的日常中是 5-15 個），其中包含一些優惠（10-30 個類別）。很多時候，這些優惠會在不同的類別中重復出現：這些優惠完全相同（firstCategory 中帶有 id="offer1" 的優惠與thirdCategory 內帶有 id="offer1" 的優惠完全相同）。
它經常發生，而且好像這還不夠，一個 Offer 元素包含許多欄位（類似于 50……在我的示例中，我出于顯而易見的原因將它們洗掉）：這會導致非常大的回應。
我想知道通過如下設定的參考系統嘗試解決問題是否是正確的做法：
{
"catalog": {
"categories": [
{
"id": "firstCategory",
"name": "The first category!",
"order": 0,
"idOffers": [ "offer1", "offer2", "offer3" ]
},
{
"id": "secondCategory",
"name": "The second category!",
"order": 1,
"idOffers": [ "offer2", "offer3", "offer4" ]
},
{
"id": "thirdCategory",
"name": "The third category!",
"order": 2,
"idOffers": [ "offer1", "offer4", "offer5" ]
}
],
"offers": [
{
"id": "offer1" // a LOT of fields... but written only once
},
{
"id": "offer2" // a LOT of fields... but written only once
},
{
"id": "offer3" // a LOT of fields... but written only once
},
{
"id": "offer4" // a LOT of fields... but written only once
},
{
"id": "offer5" // a LOT of fields... but written only once
}
]
}
}
雖然對我來說它看起來更實用、更干凈，但我想知道的是：這是一種不好的做法嗎？
PS：如果有人想知道發出兩個類似GET catalog/categories和GET catalog/{idCategory}/offers
或類似的請求是否更正確，他必須知道，出于各種業務和架構原因，要發出的請求必須只保留一個。
uj5u.com熱心網友回復：
你的建議沒有本質上的錯誤；這可能是一個更好的方法。除了減少有效負載大小的明顯好處外，您的建議還將消除資料例外的可能性。現有結構中可能會出現例外情況，因為它允許同一報價的兩個不同“副本”具有不相符的屬性值。如果您不完全信任資料源，那么您可能會覺得需要驗證傳入的報價。但是您甚至不能這樣做，因為您可以將（比如說）offer1 的眾多副本中的哪一個視為“主”副本？
正是因為這個原因，Ted Codd 發明了第一范式，俗稱“消除重復組”。
我說過這很可能是一種更好的方法，但它是否真的是一種更好的方法取決于您的背景關系。例如，如果您想立即將此資料存盤在關系資料庫中，那么這絕對是一個更好的方法，因為規范化已被推到上游，可能會回到源頭，但肯定超出了您的應用程式的范圍，這意味著您沒有不必擔心上述例外情況，并且您需要處理的資料更少。
另一方面，如果您想生成分層報告 - 或將資料存盤在類似于您收到的分層結構中，那么它就不是那么明確了。我仍然認為消除例外風險是一個巨大的收益，有效載荷大小的潛在大幅減少也是如此，但是您可能會付出代價，必須將報價快取在某處，然后必須“查找”報價資料作為你處理每個idOffers陣列。如果性能受到嚴重影響，您可能需要權衡這些事情。如果報價數量相對較少，我懷疑這會是一個問題。
所以我認為你的直覺是合理的。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/359709.html
上一篇：JOLT轉換-嵌套的Json物件