对于多语言电子商务网站来说,高效的 MongoDB 模式设计是什么?

发布于 2024-12-06 07:02:20 字数 635 浏览 4 评论 0原文

我正在设计一个多语言电子商务网站。产品具有不同的特性。某些属性对于每种语言都是不同的(例如颜色),其他属性对于所有语言都是相同的(例如 SKU)。属性不是预定义的,例如汽车具有除浓缩咖啡机之外的其他属性。

我想设计数据库模式,以便:

  1. 用 y 语言搜索和表示类别 x 的所有产品速度很快 重复
  2. 数据量很少
  3. 我不想使用带翻译的文件

我正在考虑使用模式像这样:

{
 _id: ObjectID("5dd87bd8d77d094c458d2a33"),

 multi-lingual-properties: ["name", "description"],

 name: { en: "Super fast car",
         nl: "Hele snelle auto"},

 description: { en: "Buy this car",
                nl: "Koop deze auto"},

 price: 20000,

 sku: "SFC106X",

 categories: [ObjectID("4bd87bd8277d094c458d2a43")]
}

这个模式有更好的替代方案吗?当我使用这个模式时会遇到什么问题?

I'm designing a multilingual e-commerce site. Products have different properties. Some properties are different for each language (like color), other properties are the same for all languages (like SKU). Properties are not predefined, for example cars have other properties than espresso machines.

I'd like to design the database schema such that:

  1. Searching and representing all products from category x in language y is fast
  2. The amount of duplicate data is low
  3. I don't want to use files with translations

I'm thinking about using a schema like this:

{
 _id: ObjectID("5dd87bd8d77d094c458d2a33"),

 multi-lingual-properties: ["name", "description"],

 name: { en: "Super fast car",
         nl: "Hele snelle auto"},

 description: { en: "Buy this car",
                nl: "Koop deze auto"},

 price: 20000,

 sku: "SFC106X",

 categories: [ObjectID("4bd87bd8277d094c458d2a43")]
}

Is there a better alternative to this schema? What problems will I encounter when I use this schema?

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

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

发布评论

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

评论(1

梅倚清风 2024-12-13 07:02:20

比我预期的要晚,但这是我们现在正在实施的...

背景:我们的系统应该能够从多个电子商务网站导入产品库存,因此灵活性和可扩展性。国际化很重要。

EAV 模型:

db.products.find()

{ "_id" : ObjectId("4e9bfb4b4403871c0f080000"), 
"name" : "some internal name", 
"sku" : "10001", 
"company" : { /* reference to another collection */ }, "price" : 99.99,
"attributes": { 
  "description": { "en": "english desc", "de": "deutsche Beschreibung" },
  "another_field": { "en": "something", "de": "etwas"}, 
  "non_i18n_field": { "*": xxx } 
 }
}

我们还需要属性的元数据,其中包括管理编辑提示(使用什么输入表单)和属性名称的国际化。示例:

db.eav.attributes.find()

{ "_id" : ObjectId("127312318"), 
"code" : "description", 
"labels" : { "en" : "Description", "de": "Beschreibung" }, 
"type" : "text-long", 
"options" : [], 
"constraints" : [ ]
}

这个想法是属性元数据将非常大并且不会被复制。大多数情况下,操作将使用(动态)属性的值来完成。如果需要属性元数据来显示 UI 等,则可以加载并加载它。单独缓存,并由属性代码引用。

因此,默认情况下,所有属于属性的内容都是支持 i18n 的。

i18n-enabled-attributes 的查询很简单:

db.products.find({ attribute.description.en: "searched val" })

未翻译的属性可能会很麻烦,因为它们需要在查询中进行特殊处理:

attributes.description .*

还不确定我们将如何处理这些属性。例如,数值不需要翻译。欢迎对此有任何想法。

但我们仍然没有使用这种结构,因此这些实际上是实现前的想法。我预计当我们开始在实践中使用它时,会出现更多问题,即为 CRUD 操作进行 UI 等。

Later than I expected, but here's what we're implementing now...

Background: Our system is supposed to be able to import product inventory from multiple ecommerce sites, so flexibility & i18n are important.

EAV model:

db.products.find()

{ "_id" : ObjectId("4e9bfb4b4403871c0f080000"), 
"name" : "some internal name", 
"sku" : "10001", 
"company" : { /* reference to another collection */ }, "price" : 99.99,
"attributes": { 
  "description": { "en": "english desc", "de": "deutsche Beschreibung" },
  "another_field": { "en": "something", "de": "etwas"}, 
  "non_i18n_field": { "*": xxx } 
 }
}

We also need metadata for attributes, which includes admin editing tips (what input forms to use) and i18n for names of the attributes. Example:

db.eav.attributes.find()

{ "_id" : ObjectId("127312318"), 
"code" : "description", 
"labels" : { "en" : "Description", "de": "Beschreibung" }, 
"type" : "text-long", 
"options" : [], 
"constraints" : [ ]
}

The idea is that attribute metadata will be quite large and won't get copied. Most of the time operations will be done using values of the (dynamic) attributes. If attribute metadata is necessary to display UI etc. it can be loaded & cached separately, and referenced by the attribute code.

So by default everything that's an attribute is i18n-enabled.

Queries for i18n-enabled-attributes are simple:

db.products.find({ attributes.description.en: "searched val" })

Non translated attributes may be a hassle though since they'd need special treatment in queries:

attributes.description.*

Not sure what we'll do with those attributes yet. E.g. numeric values don't require translation. Any thoughts on that are welcome.

We're still not using this structure though, so these are really pre-implementation ideas. I'm expecting more issues to surface while we start using this in practice, i.e. doing UI for CRUD operations etc.

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