我有一个现有的数据库,可以模拟所有products
,company
正在生产或消费。数据库非常简单:
Table: companies {PK: company_id}
+------------+--------------+
| company_id | company_name |
+------------+--------------+
Table: products {PK: product_id}
+------------+--------------+---------------+
| company_id | product_id | product_price |
+------------+--------------+---------------+
现在,如果我需要向其添加location
信息,它就会变得复杂起来。
基本上,现在company
有很多locations
,每个location
有很多products
。
为了使问题更加复杂,product
的一些属性,例如每个price
的{{1}}可能不一样。我想在所有location
分享其他常见属性(基本上,我想避免创建在所有三个位置都使用的产品A的三个副本。)
我不确定这种模型的最佳方法是什么。我能想到
locations
但是这种设计不允许Table: company_location
+------------+-------------+
| company_id | location_id |
+------------+-------------+
Table: location_product
+-------------+------------+
| location_id | product_id |
+-------------+------------+
属性按product
进行更改,而不会为每个位置创建完全不同的产品。我也无法按location
维护主product
列表。
感谢任何帮助。
PS:我正在使用postgreSQL数据库
答案 0 :(得分:1)
规范化规则会告诉您,您需要非关键属性来依赖所有关键值(而不是其他)。
如果价格由以下因素确定: - 制造它的公司 - 销售它的位置 - 产品究竟是什么
然后这意味着PRICE
需要一个指定公司,位置和生产的候选键。
问题变成了公司,产品和地点之间的关系。另外,关于这三种事情你还知道什么(你有哪些专栏)?
如果它们都是完全独立的,例如,产品是商品,完全不依赖于公司,而且这些地点是独立的经销商,这与任何公司无关或在那里销售什么样的产品,那么真正的单向三连接可能是你最好的选择。
但是,如果公司,产品和位置之间存在某些链接,那么您需要适当地规范化这些项目。最后,您可能仍然发现自己很想将价格作为三向联接的唯一属性。或者,您可能会发现您的数据实际上更加层次化(公司的销售地点与其他地方销售的类似产品在某些方面存在根本差异)。在这种情况下,价格可能存在于树结构的叶级上。
如果不更好地了解您的业务规则,很难确定哪种方法最适合您。
底线是,你应该瞄准第三范式(3NF)。