首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >多存储、分级分类的产品目录数据库

多存储、分级分类的产品目录数据库
EN

Stack Overflow用户
提问于 2018-11-27 10:20:09
回答 1查看 830关注 0票数 0

我正在寻求对最佳数据库(不管是关系数据库还是非关系数据库)的决定以及给定任务的最佳模式的帮助。

其思想如下:有一个具有多个商店的离线商店网络(~10)。每家商店都有多个产品(~100000),在它们之间共享,但可用性和价格/折扣有所不同。产品按层次结构分类(~1000)。有些类别可以是折扣-类别。有些不是。有些产品可能是成人产品。产品具有多种属性。

所需的查询:

  • 获取当前可用产品的给定商店的完整类别树(受嵌套级别的限制)(由成人标志过滤)。
  • 根据给定的类别ID获取一些子树,用于当前可用产品的给定商店。
  • 为给定商店的折扣类别获取一棵树,其产品当前可用并打折。
  • 获取给定类别中给定商店当前可用产品的分页列表,包括由成人筛选的子类别。
  • 获取包含完整属性列表的单个产品详细信息。
  • 按属性过滤产品。

当前解决方案构建在Oracle数据库之上,其模式如下:

表:storesproductscategories (通过MPTT的层次结构)、products_categories (引用productscategories)、productprices (引用storesproducts)、attributes (引用stores)、productattributes (引用d26和d27)、attributevalues (引用productattributes)。

它有点工作,但开始变慢了。例如,使用可用产品获取类别的查询有时执行时间不到1秒钟,有时执行时间超过30次,这取决于数据库中当前导入的数据。

所涉问题如下:

代码语言:javascript
复制
SELECT "categories".* FROM "categories"
WHERE (
  NOT ("categories"."external_id" = '_reserved' AND "categories"."external_id" IS NOT NULL)
  AND "categories"."is_promo" = 0
  AND "categories"."begins_on" <= to_timestamp('2018-11-27', 'YYYY-MM-DD')
  AND "categories"."ends_on" >= to_timestamp('2018-11-27', 'YYYY-MM-DD')
  AND (EXISTS(
    SELECT U0."id" FROM "productprices" U0
    INNER JOIN "products" U1 ON (U0."product_id" = U1."id")
    INNER JOIN "products_categories" U2 ON (U1."id" = U2."product_id")
    WHERE (
      U2."category_id" = ("categories"."id")
      AND U0."updated_at" >= to_timestamp('2018-11-27 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
      AND U0."store_id" = 42
      AND U0."begins_on" <= to_timestamp('2018-11-27 09:00:00', 'YYYY-MM-DD HH24:MI:SS')
      AND U0."ends_on" >= to_timestamp('2018-11-27 09:00:00', 'YYYY-MM-DD HH24:MI:SS')
      AND (U0."discount" IS NOT NULL OR U1."has_special_offer" = 1)
      AND U1."is_adult" = 0))
  )
)
ORDER BY "categories"."tree_id" ASC, "categories"."lft" ASC

我们目前正在开始从Oracle数据库迁移。主要的应用程序数据库将是Postgres,但对于应用程序的目录部分,我愿意看看不同的存储。或者我应该优化模式/查询?

目前有15家商店,每年增加4家。据我所知,不应该有超过20万种产品。在可预见的将来,有25家商店将价格表限制在5000行。

EN

回答 1

Stack Overflow用户

发布于 2018-11-28 12:15:43

据我所知,几百万行对于Postgres来说是可以的。我不会费心迁移到某些NoSQL解决方案。相反,专注于优化(适当的模型、索引等),并整理您提到的导入(防止长锁、大事务等)。您发送的查询应该易于索引(在Postgres上使用部分索引)。那就是我会做的。

票数 0
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/53497443

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档