我使用自己构建的数据库模型。该模型是为web商店应用程序构建的。它看起来是这样的:
首先，我有一张表来放我的产品。这只包含一般数据，如id和articlr，对于所有产品属性(如名称、价格等)，我为每种类型制作了单独的表，因此我有以下表:
product_att_varchar
product_att_decimal
product_att_int
product_att_select
product_att_text
product_att_date
这些表通过一个关系表procuct_att_relational
联系起来我的问题是这个结构的性能，如果我想要一个特定产品的所有属性，如果必须使用如此多的连接，它会变慢很多。
有人有解决方案吗??
谢谢
该模型称为EAV (entity-attribute-value)，有其缺点和优点。
优点是非常灵活，可以很容易地扩展。如果您有大量非常稀疏的属性，这些属性在设计时无法预测(例如，用户提供的)，或者很少使用的属性，那么它可能很有用。
缺点是性能和不能同时索引多个属性。但是，如果您的数据库系统允许索引视图(如SQL Server)或多表的集群存储(如Oracle)，那么使用这些技术可以提高性能。
但是，将所有属性存储在一条记录中仍然会更快。
我看不出有什么好的理由将这些属性移出产品表。如果你这样做是因为你有一些数据表明存在问题，这是一回事，但看起来你认为"这样会更好"。你为什么一开始就这么做?
如果您这样做是因为它是为您生成的，我建议您放弃该生成器。
人们不断回到这个模式，因为他们认为它是"灵活的"。嗯，我想是的，但是这种灵活性是要付出巨大代价的:每次更新和每次查询都是缓慢而复杂的。Quassnoi提到，如果属性是稀疏的，即大多数实体实例只有一小部分可能的属性，这可以节省空间。这是真的，但另一方面，如果它不是稀疏的，这将占用更多的空间，因为现在除了值之外，您还必须存储每个属性的属性名称或代码，并且您需要重复某种键来标识每个属性的逻辑实体实例。
我能想到的唯一一个好主意是如果属性列表需要动态更新，也就是说，用户需要能够决定在他喜欢的时候创建一个新属性。那么系统会对这个属性做什么呢?如果你只是想让用户能够输入，然后检索他输入的内容，这很容易。但它会以任何方式影响加工吗?比如，如果用户决定添加"清仓销售代码"，你的程序如何知道这会如何影响销售价格?当然，这是可以做到的:您可以有额外的屏幕，用户可以在其中输入数据，以某种方式描述每个字段如何影响定价或重新订购或其他内容。但这会增加更多层次的复杂性。
所以我的简短回答是:除非你有非常特殊的要求，否则不要这样做。如果你想建立一个数据库来描述你销售的商品，比如描述、价格和库存数量，那么创建一个表，包含描述、价格和库存数量。生活已经够艰难的了，如果你不想再让它变得更艰难的话。