产品变体-如何建模？不要用EAV吧？

Question

产品变体-如何建模？不要用EAV吧？

mysqldatabasedatabase-designdata-modeling

3

给定一个产品，该产品可能有不同的变体（例如大小：小号，中号，大号或颜色：白色，黑色）。如果产品有多个变体，则总变量是各个变体组合而成（例如，小白，小黑，中白，中黑，大白，大黑）。每个变体组合将被分配自己的SKU、价格、库存水平等。每种变体还将与一般的产品详细信息相关联（例如，产品名称、产品描述等）。

当您不知道变体可能是什么时，什么是最好的建模产品变体的方法？我认为可能是EAV，但我过去曾遇到过问题。想知道是否有更好的方法。

更新1：

这不是How to design a product table for many kinds of product where each product has many parameters的重复。

在阅读了接受的答案之后，我还是很困惑。似乎我的对EAV的犹豫是站得住脚的。所以也许我要远离那个解决方案。此外，如果我要使用EAV，那么价格、SKU和库存水平等始终存在的属性怎么办？我知道它们必须始终存在——因此，它们不需要EAV的灵活性。

@Bill Karwin说他的首选是使用类表继承。我不确定这对我是否适用。我需要存储数万（也许是数十万）条记录。我事先不知道变体会是什么（我的代码会在运行时解析XML源和电子表格，但不会更早）。因此，在这个阶段预测我需要哪些其他表是不可能的。

所以-我还是很困惑。我该如何建模产品变体？

- StackOverflowNewbie

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Phil Sandler · Answer 1

我并不是EAV的捍卫者，但在某些情况下它是必要的，而且听起来你的情况就是其中之一。如果你不知道在设计时需要哪些属性，那么你的选择相当有限。

使用无模式设计可能是一个选项，现在NoSQL越来越流行，但仍然涉及允许具有n个动态属性的对象/文档的怪异性。

如果符合您的需求，还可以考虑只使用BLOB或XML列来描述每个产品的动态部分。这将比EAV简化您的解决方案，但也会限制您的数据检索选项（取决于您的要求）。

此外，如果我要使用EAV，那么像价格、SKU和库存水平这样的属性怎么办？

我绝对建议您尽可能明确地建模，并将您的解决方案（XML、EAV或其他）隔离到需要它的区域。没有理由比必须更加限制自己。