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