我正在为葡萄酒和其他酒精饮料的经销商开发一个网站。显然，每种葡萄酒都是在一个必须在Wine表中建模的国家制造的。 但很多时候，葡萄酒还有一个地区（朗格多克，里奥哈，布格涅等），这些地区当然是与一个国家的亲子关系。 存在以下选项：
- 仅向Wine表提供对区域的引用 问题是一些葡萄酒/威士忌没有提到一个地区，只提到一个国家
- 将葡萄酒表2个单独的FK引用，分配给Country和Region表。由于国家和地区已经相关，因此引入了循环引用和冗余问题。
- 使用Wine表中的Location表和单个FK引用到Location表。位置表实际上是一个地区或国家（甚至可能是一个城市），所以它有一个字段“location_type”和一个父FK字段，指的是它自己的PK。对于顶级国家/地区条目，父标识为空。 这是我在互联网上找到的一个例子。然而，它会使查询更复杂。
这是一个已知问题，有什么建议吗？ TIA，Klaas
答案 0 :(得分：1)
我也正在开发这个领域的应用程序。葡萄酒的常见之处还有分区域或称谓的概念，因此您可以品尝法国勃艮第 - 科特迪瓦的葡萄酒。我选择了你描述的第二个选项，FK引用了Country，Region和Subregion。只需要Country字段，而其他字段可以为空。引用完整性的潜在问题与此模型相结合，但它极大地促进了基于这些字段的有效查询，这是首先捕获此信息的一种方式。
答案 1 :(得分：0)
我认为您可能希望从维度分析的角度来看待这一点，而不是严格的实体关系。也就是说，非规范化可能正是您正在寻找的。我会推荐Ralph Kimball关于维度数据仓库的书籍，因为它们经常解决这类问题。
在您的情况下，只需创建一个“位置”维度，其中包含您可能感兴趣的所有字段，并且粒度最低：
这两个是显而易见的。你可能也有山坡，城市等等。
举一个例子，您将拥有以下行：
葡萄酒会与这张桌子相连。
现在，您对此表存在维护问题。然而，葡萄酒和官方地区的世界是众所周知的，并且变化非常缓慢，所以我不认为这是一个问题。
答案 2 :(得分：0)
创建位置维度的好点。这种类型的模型更有效地解决了分析问题，但对于事务系统来说更复杂。这就是您是在优化模型以处理CRUD类型事务还是聚合数据分析的问题。
总的来说，我认为Klaus正在研究具有基本查询的事务系统的建模，而不是像数据仓库那样的基于分析的应用程序。