我一直试图用https://github.com/paularmstrong/normalizr
为我的redux商店规范化嵌套数据登录用户后，我会收到回复，其中包含他们的信息以及与其他数据类型的关系。
{
"data": {
"id": "207",
"type": "users",
"attributes": {
"email": "roberta@nitzsche.biz",
"last-sign-in-at": null,
"username": "april.johns",
"first-name": "Audie",
"last-name": "Halvorson",
"short-bio": "Ut exercitationem ",
"bio": "Ut exercitationem totam perferendis consequatur dolorem veritatis dolorem.",
"location": null,
"gender": "male",
"birthday": "1986-10-07",
"email-digest": "daily_digest",
"email-notifications": "instantl_notifications",
"auth-token": "_HV-S6qrdobecr-rr6gs",
"avatar-large-2x": "/missing_avatar.png",
"avatar-large": "/missing_avatar.png",
"cover-desktop-2x": "/missing_cover.png",
"cover-desktop": "/missing_cover.png",
"cover-mobile-2x": "/missing_cover.png",
"cover-mobile": "/missing_cover.png",
"wp-id": null,
"created-at": "2016-10-07T23:16:13.565Z",
"updated-at": "2016-10-07T23:16:13.565Z"
},
"relationships": {
"websites": {
"data": [
{
"id": 11,
"url": "http://mohr.org/coy_rowe",
"user-id": 207,
"created-at": "2016-10-07T23:16:13.651Z",
"updated-at": "2016-10-07T23:16:13.651Z"
}
]
},
"books": {
"data": [
{
"id": 11,
"name": "Outdoors & Industrial",
"image-url": "https://robohash.org/sitveritatisab.png?size=300x300&set=set1",
"author": "Meggie Balistreri",
"created-at": "2016-10-07T23:16:13.629Z",
"updated-at": "2016-10-07T23:16:13.629Z"
}
]
},
"movies": {
"data": [
{
"id": 11,
"name": "Movies, Home & Electronics",
"image-url": "https://robohash.org/quiaarchitectoodit.png?size=300x300&set=set1",
"author": "Eveline Ziemann",
"created-at": "2016-10-07T23:16:13.642Z",
"updated-at": "2016-10-07T23:16:13.642Z"
}
]
},
"interests": {
"data": [
{
"id": 22,
"name": "Synergistic Aluminum Gloves",
"created-at": "2016-10-07T23:16:13.596Z",
"updated-at": "2016-10-07T23:16:13.596Z"
}
]
},
"virtues": {
"data": [
{
"id": 22,
"name": "Ergonomic Wool Gloves",
"created-at": "2016-10-07T23:16:13.582Z",
"updated-at": "2016-10-07T23:16:13.582Z"
}
]
},
"features": {
"data": [
]
},
"strengths": {
"data": [
{
"id": 22,
"name": "Ergonomic Wool Gloves",
"created-at": "2016-10-07T23:16:13.582Z",
"updated-at": "2016-10-07T23:16:13.582Z"
}
]
},
"teachers": {
"data": [
{
"id": 22,
"name": "Ergonomic Wool Gloves",
"created-at": "2016-10-07T23:16:13.582Z",
"updated-at": "2016-10-07T23:16:13.582Z"
}
]
}
}
}
}
在阅读了很多教程之后，我相信我的数据标准化最能代表这种形状。
"currentUser" {
"lastUpdated": 0,
"userId": 207,
"attributes": {
"email": "roberta@nitzsche.biz",
"last-sign-in-at": null,
"username": "april.johns",
"first-name": "Audie",
"last-name": "Halvorson",
"short-bio": "Ut exercitationem ",
"bio": "Ut exercitationem totam perferendis consequatur",
// etc....
},
"relationships": {
"websites": [11],
"books": [22],
"movies": [33],
"interests": [21],
"virtues": [34],
"features": [22],
"strengths": [15],
"teachers": [45],
}
}
这是否意味着我为所有关系类型创建了模式？
网站 图书 电影 利益 美德 特征 优势 教师
然后使用嵌套的所有模式定义一个relationshipSchema？对于这种关系，所有类型都会在网站外的不同区域被引用。
ex）他们选择兴趣的页面，我得到了所有兴趣的回复。
[
{
"id": 54,
"name": "Fantastic Wooden Hat",
"created_at": "2016-10-12T18:54:01.669Z",
"updated_at": "2016-10-12T18:54:01.669Z"
},
{
"id": 55,
"name": "Fantastic Wooden Hat",
"created_at": "2016-10-12T18:54:01.669Z",
"updated_at": "2016-10-12T18:54:01.669Z"
},
{
"id": 56,
"name": "Fantastic Wooden Hat",
"created_at": "2016-10-12T18:54:01.669Z",
"updated_at": "2016-10-12T18:54:01.669Z"
},
{
"id": 57,
"name": "Fantastic Wooden Hat",
"created_at": "2016-10-12T18:54:01.669Z",
"updated_at": "2016-10-12T18:54:01.669Z"
}
]
我也正常化......
{
54: {
"id": 54,
"name": "Fantastic Wooden Hat",
"created_at": "2016-10-12T18:54:01.669Z",
"updated_at": "2016-10-12T18:54:01.669Z"
},
55: {
"id": 55,
"name": "Fantastic Wooden Hat",
"created_at": "2016-10-12T18:54:01.669Z",
"updated_at": "2016-10-12T18:54:01.669Z"
},
56: {
"id": 56,
"name": "Fantastic Wooden Hat",
"created_at": "2016-10-12T18:54:01.669Z",
"updated_at": "2016-10-12T18:54:01.669Z"
},
57: {
"id": 57,
"name": "Fantastic Wooden Hat",
"created_at": "2016-10-12T18:54:01.669Z",
"updated_at": "2016-10-12T18:54:01.669Z"
}
}
任何帮助都将受到高度赞赏，也有文章，教程，视频示例。
谢谢，
答案 0 :(得分：3)
您无需展平没有ID的项目。没有ID的项目不能引用。
您可以像在任何地方一样添加ID，但请注意，除非您计划从多个地方引用这些项目，否则展平层次结构没有任何好处。它只会增加不必要的复杂性。
即使您的商品已经有ID，除非您打算按该ID引用这些商品，否则在展平层次结构时没有用处。
您应该展平层次结构的一种情况是当一个项目被多个其他对象使用时。这里的引用是至关重要的，因为否则当项目在一个地方被修改时，它可以在其他地方保持相同，即使你试图阻止它，因为由不知道有多个副本的人做出的错误或后来的代码更改。这导致了不同的副本，这些副本本质上是数据损坏。
关系数据库通常引用仅引用一次的项，因为其中许多项不支持每行层次结构。这可以通过使用address_street和address_city之类的名称来缓解，而不是创建单独的地址表。在这种情况下制作单独的表是不正常的规范化。
另一方面，对象数据库对单个对象中的分层数据没有任何问题。
在某些情况下，子对象仍然具有id。例如，在Mongo DB中，数组中的对象具有id。这允许DB识别删除和重新排序。在React中，key道具存在的原因完全相同。
您也可以在自己的代码中使用这样的id用于相同的目的，而不会使层次结构扁平化。
请注意，从代码引用项目可能也构成参考。
例如，如果您有一个组件WebSiteEditor并且您不展平了层次结构，则组件需要知道网站的ID以及用户的ID该网站属于谁。如果您执行展平层次结构，则此组件只需要id。
嵌套项目的ID只需要在本地唯一，而顶级项目的ID必须是全局唯一的，或者每个集合至少是唯一的。
我的建议是不要展平项目，除非这些项目是从多个地方引用的。