多用途的应用程序的理想数据建模是什么?

发布于 2025-01-31 19:09:09 字数 1226 浏览 2 评论 0原文

查看了Firestore文档 + Google的I/O 2019网络研讨会,但我仍然不清楚针对我的特定用例的正确数据建模。

  1. APP使专业服务提供商可以在预定义的类别(停留,体育,健康...)和预定义的价格点(50 $,75 $,100 $ ...)中注册并发布其一项或多种服务。
  2. 主页上的用户是首先使用价格点滑块过滤 - 请参见线框),例如:199€,然后是 ,通过选择类别,例如:所有“体育”(在199€)以及位置(例如:所有体育运动在英国199欧元)。 选择的是,因为用户也可以在选择价格后立即使用按钮构建列表。相同的“构建列表”按钮在类别选择之后和位置选择之后。因此,可能有3个过滤深度。

考虑到每次过滤时我想避免数千读读取,这将是理想的数据结构。 三个根级收集(服务提供商,价格点,服务类别?)与他们的相关文件?我理解并接受贬值是为了过滤的目的。

这是更好地理解过滤的线框:

“

”第一个199eur价格选择后的搜索结果

”'Sports'类别选择后进一步过滤

“

Viewed the Firestore docs + Google's I/O 2019 webinar, but I'm still not clear about the right data modeling for my particular use case.

  1. App lets pro service providers register and publish one or more of their services in pre-defined categories (Stay, Sports, Wellness...) and at pre-defined price points (50$, 75$, 100$...).
  2. Users on the homepage are to filter down first with a price point slider - see wireframe), e.g: 199€, then and optionally by selecting the category, eg: all 'Sports' (at 199€) and the location (e.g: all sports at 199€ in the UK). Optionally because users can also build their list with a button as soon as the price is selected. The same 'build list' button is after the category selection and after the location selection. So 3 depths of filtering are possible.

What would be the ideal data structure, given that I want to avoid thousands of reads each time there's filtering.
Three root-level collections (service providers, price points, service categories?) with their relevant documents? I understand and accept denormalization for the purpose of my filtering.

Here's the wireframe for a better understanding of the filtering:

homepage

search result after first 199EUR price selection

further filtering after 'Sports' category selection

Location filtering

proposed data modeling

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

旧时浪漫 2025-02-07 19:09:10

应用程序使专业服务提供商可以注册并以预定义的类别(停留,体育,健康...)和预定的价格(50 $,75 $,100 $。 。)。

由于您拥有预定义的类别,价格和位置,因此建模此类数据库的最简单解决方案就是拥有一个产品集合:

Firestore-root
  |
  --- products (collection)
        |
        --- $productId (document)
               |
               --- name: "Running Shoe"
               |
               --- category: "Sport"
               |
               --- price: 199
               |
               --- location: "Europe"
               |
               --- country: "France"

这样,您只需执行所有需要的查询即可。由于您没有指定编程语言,因此我将在Java中编写查询,但是您可以将它们转换为任何其他编程语言。因此,例如,您可以以特定价格查询所有产品:

FirebaseFirestore db = FirebaseFirestore.getInstance();
Query queryByPrice = db.collection("products").whereEqualTo("price", 199);

如果您需要按价格,类别和位置查询,则必须链接多个weryequalalto()方法:

Query queryByPrice = db.collection("products")
                       .whereEqualTo("price", 199)
                       .whereEqualTo("category", "Sport")
                       .whereEqualTo("location", "Europe");

但是,如果您需要要订购结果,上升或下降,也不要忘记创建一个 index

鉴于我想每次过滤时都要避免数千读的理想数据结构。

如果您不需要一次获得所有结果,则必须实现分页。如果您需要提前知道运动类别中存在的产品数量,那么如果不执行查询并计算可用产品,则不可能。我写了一篇有关此主题的文章,称为:

另一个可行的可能解决方案是创建一个包含所有这些数字的单个文档。换句话说,正是您向用户显示的内容,这些屏幕截图中存在的所有内容。这样,您只需要支付一个读取操作即可。当用户单击特定类别时,只有这样您才能执行实际搜索。

我理解并接受过滤的目的。

在这种情况下,无需将数据归政。有关此类操作的更多信息,请在下面查看我的答案:

App lets pro service providers register and publish one or more of their services in pre-defined categories (Stay, Sports, Wellness...) and at pre-defined price points (50$, 75$, 100$...).

Since you're having pre-defined categories, prices, and locations, then the simplest solution for modeling such a database would be to have a single collection of products:

Firestore-root
  |
  --- products (collection)
        |
        --- $productId (document)
               |
               --- name: "Running Shoe"
               |
               --- category: "Sport"
               |
               --- price: 199
               |
               --- location: "Europe"
               |
               --- country: "France"

In this way, you can simply perform all queries that you need. Since you didn't specify a programming language, I'll write the queries in Java, but you can simply convert them into any other programming language. So for example, you can query all products with a particular price:

FirebaseFirestore db = FirebaseFirestore.getInstance();
Query queryByPrice = db.collection("products").whereEqualTo("price", 199);

If you need to query by price, category and location, then you have to chain multiple whereEqualTo() methods:

Query queryByPrice = db.collection("products")
                       .whereEqualTo("price", 199)
                       .whereEqualTo("category", "Sport")
                       .whereEqualTo("location", "Europe");

If you, however, need to order the results, ascending or descending, don't also forget to create an index.

What would be the ideal data structure, given that I want to avoid thousands of reads each time there's filtering.

If you don't need to have all the results at once, then you have to implement pagination. If you need to know the number of products that exist in the sports category ahead of time, that is not possible without performing a query and counting the available products. I have written an article regarding this topic called:

Another feasible possible solution would be to create a single document that contains all those numbers. In other words, exactly what you're displaying to the users, everything that exists in those screenshots. In this way, you'll only have to pay a single read operation. When the users click on a particular category, only then you should perform the actual search.

I understand and accept denormalization for the purpose of my filtering.

In this case, there is no need to denormalize the data. For more info regarding this kind of operation, please check my answer below:

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文