我目前正在使用一项服务构建一个小型应用程序,该服务需要并提倡使用" flattened"数据模型(该服务是Firebase)。
由于我以前没有数据模型的经验,我想知道我是否以正确的方式压扁了我的数据。
这是我开始使用的数据模型模型(它有很多嵌套节点):
// Core data model
{
// All registered users
"users": {
// User assigned ID
"userid": {
// User information
"password": "password",
"email": "test@gmail.com",
"name": "test",
// Saved user entries
"entries": {
// Entry ID
"entryid": {
// Firt part of entry
"first": {
"one": "yay",
"two": "nice",
"three": "man"
},
"second": {
"one": "wow",
"two": "hmm",
"three": "nope"
}
},
"entryid2": {
"first": {
"one": "kewl",
"two": "look",
"three": "this"
}
}
}
},
"id2": {
// ... and so on
}
}
}
这是我的"扁平"版本:
// Flattened model
{
// All registered users
"users": {
// User assigned ID
"userid": {
// User information
"password": "password",
"email": "test@gmail.com",
"name": "test"
},
"userid2": {
// ... and so on
}
},
// All user entries
"entries": {
// User assigned UD (entries for particular user)
"userid": {
"first": {
"one": "yay",
"two": "nice",
"three": "man"
},
"second": {
"one": "kewl",
"two": "look",
"three": "this"
}
},
"userid2": {
"one": "wow",
"two": "hmm",
"three": "nope"
}
}
}
了解这是否是以扁平化方式组织数据的正确(或至少可能)方式将非常有用。
答案 0 :(得分:2)
实际上没有100%正确的方式来存储数据。从心理开销的角度来看,它是适合您的组合,以及您正在使用的任何商店的技术限制。
尽管Firebase确实倡导“平面数据结构”,但您的代码示例不会接近其技术限制。
子节点的密钥不能超过768字节,也不能超过32 水平
你只是向两个节点深入,我建议你选择你能理解和最佳沟通的数据模型,因为你不太可能在上面发布的范围内遇到技术限制。