模型 Firestore 数据答案

【问题标题】：Model Firestore Data模型 Firestore 数据
【发布时间】：2018-09-09 18:18:19
【问题描述】：

我正在使用 Firestore 创建一个新数据库。我是 NoSQL 的新手，并试图确定为我的数据建模的最佳实践。我知道默认情况下 Firestore 数据很浅（与实时数据库相反），因此嵌套不是问题。也就是说，为或多或少的标准用户对象建模的最佳方法是什么？

选项 1 - 仅限家长级别：

users {
    uid {
        name: 'Bob',
        officeNumber: 1234567890,
        faxNumber: 0987654321,
        email: 'test@test.com',
        domain: '@test.com',
        facebook: 'bobdylan97',
        twitter: 'bobbystwitter',
        instagram: 'bobinsta',
        street: '111 N Elm St',
        city: 'Brooklyn',
        state: 'NY',
        zip: 12345,
        height: 72,
        weight: 200,
        hairColor: 'brown',
        eyeColor: 'blue'
    }
}

选项 2 - 嵌套多个级别：

users {
    uid {
        personal {
            name {
                first: 'Bob',
                last: 'Dylan'
            },
            attributes {
                height: 72,
                weight: 200,
                hairColor: 'brown',
                eyeColor: 'blue'
            }
        },
        contact {
            phone {
                office: 1234567890,
                fax: 0987654321
            },
            email: 'test@test.com',
            domain: '@test.com',
            social {
                facebook: 'bobdylan97',
                twitter: 'bobbystwitter',
                instagram: 'bobinsta'
            }
        },
        address {
            street: '111 N Elm St',
            city: 'Brooklyn',
            state: 'NY',
            zip: 12345
        }
    }
}

我正在为其构建的公司正在成长，并且可能会在不同的点添加额外的数据，因此扩展是一个潜在的问题。像选项 2 那样对数据进行分组是否有任何问题或顾虑？像这样对数据建模的最佳实践是什么？为查询或组织优化模型的最佳做法是什么？

【问题讨论】：

我刚刚偶然发现了另一个问题，这个问题可能比我自己的措辞更好，并解决了我面临的一些问题。 Firestore: Working with nested single queries
如果您使用的是 OOP，那么您可以将其存储为 #1 以便于过滤/排序/查询，并且在您的解决方案中，您将拥有一个更像 #2 的 User 对象和一个映射器将 #1 映射到 #2，

标签： json database firebase nosql google-cloud-firestore

【解决方案1】：

完美诠释了 Firestore 的基本概念。

【讨论】：

我实际上已经在频道上观看了该视频和许多其他视频，但我认为它并不能完全回答我的问题。那个视频很棒，我已经使用这些信息尽可能地对所有内容进行建模；我已经创建了对所有内容的子集合或引用，它们的大小会大幅增长以允许缩放。但是，我的问题是关于组织不一定会增长很多的数据。例如，将所有地址信息嵌套到一个对象中是否更好？联系方式呢？根据我所知道的一切，我想这样会更好。
第一个选项更容易查询。我的意思是您选择用户，然后选择属性并完成。另一方面，第二种方法更有条理，更易读，但它也需要更复杂的查询。
是的，我想这最终是我的问题。在建模数据方面是否有标准或最佳实践？最佳做法是对数据进行建模以便更容易查询还是更好地组织起来？
恕我直言，最好让数据更有条理并使它们易于扩展。

【解决方案2】：

如果您将用户存储在 users 集合中并且 uid 是文档 ID，那么 选项 2 应该适合您。

您仅在文档中存储了有关每个用户的少量数据，因此您不应达到 1Mb 的限制。你也可以在这里压缩一个 base64 编码的个人资料图片，没有问题。

【讨论】：