如何构建具有一系列部件的存储库实体
我有一个产品实体，它有几个类（每个产品类型都有不同的字段，有数千种产品类型）。 一个产品类别可能是一把锤子，其中包含“手柄长度”、“头部重量”等字段。另一个产品类别可能是一把椅子，包含“坐垫材料”、“弹簧盒”等字段。客户根据自己的情况添加字段特定需求，几乎就像图像目录中的关键字一样。 这些最终成为搜索字段，但我们不想使用纯文本搜索，因为产品将具有适合产品类别的特定形式。
该产品分为描述、图像和价格三种字段，类似于：
Product.Desc.HandleLength
Product.Desc.HeadWeight
Product.Image.FrontFace
Product.Price.RetailCost
Product.Price.ManufacturersSalePrice
我可以将其简化为：
Product.Desc["HandleLength"]
Product.Desc["HeadWeight"]
Product.Image["FrontFace"]
Product.Price["RetailCost"]
Product.Price["ManufacturersSalePrice"]
最好让存储库实体是一个具有三个不同内容数组的对象吗？< /strong> 关于表示这样的对象的好方法有什么想法吗？ 我什至正在考虑某种“工厂存储库”哈哈。
I have a product entity which has several classes (each product type has different fields with thousands of product types). One product class could be a hammer which would have fields of "handle length", "head weight", etc. Another could be a chair with fields of "cushion material", "box spring", etc. Customers add fields based on their specific needs, almost like Keywords to an image catalog. These end up being search fields, but we don't want to use plain text searching because the products will have specific forms that cater to the product class.
The product breaks down in to three kinds of fields of description, image, and price similar to:
Product.Desc.HandleLength
Product.Desc.HeadWeight
Product.Image.FrontFace
Product.Price.RetailCost
Product.Price.ManufacturersSalePrice
Which I could simplify to:
Product.Desc["HandleLength"]
Product.Desc["HeadWeight"]
Product.Image["FrontFace"]
Product.Price["RetailCost"]
Product.Price["ManufacturersSalePrice"]
Would it be best to have the repository entity be an object with three arrays of content that varies? Any ideas on a good way to represent an object like this? I was even considering some sort of "factory repository" lol.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您的描述（或图像）可以在多个产品之间共享，请为它们定义一个单独的表，否则只需将
HandleLength等保留为主表的字段。如果您的属性严重依赖于产品（即，至少有十个属性不被所有产品共享），那么您应该考虑创建一个类表：
、一个类属性表
和一个价值表
价格往往尺寸缓慢变化。
您应该选择其中一种存储方式（
类型 1、类型 2等），具体取决于它们更改的频率以及保存价格历史记录的要求。If your desctiptions (or images) can be shared between multiple products, define a separate table for them, otherwise just keep
HandleLengthetc. as the fields of the main table.If your properties are heavily product-dependent (i. e. there are at least ten properties that are not shared by all products), then you should consider creating a class table:
, a class-property table
, and a value table
Prices tend to be slowly changing dimensions.
You should pick either of the ways to store them (
type 1,type 2etc.), depending on how often they change and what are your requirements for keeping the price history.