我有公司,客户,供应商等表,这些表都有地址信息相关列。
我想知道是否应该创建一个新表'addresses'并将所有地址列分开。
在所有表上都有地址列很容易使用和查询,但我不确定从良好的设计角度来看是否是正确的方法,让几个表重复这些相同的列让我很好奇。
地址内容对我来说并不重要,我不会在任何决策过程中检查或使用这些地址,它们纯粹与信息有关。目前我正在查看5个具有地址信息的表
答案 0 :(得分:6)
所有设计问题的答案都是:
取决于。
所以基本上,在地址案例中,它取决于每个客户是否会有超过1个地址。如果您将有多个,请将其放在新的地址表中,并为每个地址指定一个CustomerID。创建通用地址表并将其映射到公司/客户/供应商表是一种过度杀伤(大部分时间,取决于!)。
在对象之间的多对多关系中映射地址通常也有些过分(而且很危险)(如果你这样做,地址似乎会在用户身上发生神奇的变化)。
一大规则是:保持简单!
答案 1 :(得分:4)
这称为Database Normalization。是的,如果没有其他原因,你想要将它们分开,因为如果你需要在将来使用代码和查询时会更加困难。
作为一项规则,您应该始终使用第三范式设计您的数据库,即使对于简单的应用程序(在某些情况下您不会出于性能或后勤原因,但是从一开始我总是会尝试制作它第3范式,然后在你知道正确的方法之后学会欺骗)。
编辑:为了扩展这一点并添加我在其他帖子上发表的一些评论,我非常相信,当涉及到代码和重构,当它变得过于复杂时,从一个简单的设计开始更深入的面向对象原则是合适的。但是,重构生产中的数据库并不是那么简单。这完全是关于投资回报率。从一开始就设计一个规范化的数据库以证明不这样做是很容易的。设计糟糕的数据库的后果可能是灾难性的,在您实现这一目标之前通常为时已晚。
答案 2 :(得分:1)
如果您只在自己的表范围内使用这些地址,那么将它们移动到自己的表中可能没有什么好处。
基本上,这听起来不值得付出努力。
答案 3 :(得分:1)
是的,您应该将地址分成自己的表。要知道这是明智之举。这里的关键是地址的一般格式是相同的,无论它是谁;客户,公司,供应商......他们都有相同的地址字段。
使这个值得的是将地址视为原子元素的能力;也就是说,您可以概括与地址相关的所有功能,并让它只处理一个表,而不必担心它处理多个表,以及可能发生的相关模式漂移。
答案 4 :(得分:0)
如果表之间存在重叠(即在公司表和供应商表中输入相同的组织),并且两个表中的地址应始终相同,则可能值得将地址移至其自己的表中,从其他三个表中获取外键。这样,您只需在更改时在一个位置更新它。
如果这三个表完全相互独立,那么将数据移动到另一个表中并没有太大的收获,所以你不妨把它放在一边。
答案 5 :(得分:0)
我认为这完全取决于数据库的用途。不可否认,所有地址信息在结构上都是相同的,从理论的角度来看,所有地址信息都应该在一个表中,通过密钥从父表链接。
但是从性能和查询的角度来看,将它们保存在各自的表中确实从报告的角度简化了事情。
我当前公司[物流]的情况是,地址实际上在逻辑上相同 - 无论是取货地点,交货地点,客户等,它们都是所有地点。
在我的情况下,我会说他们绝对应该都在一张桌子里。但是,如果从供应商,客户,联系信息的角度来看它,我会说,虽然理论上将地址放在一个表中很好,但在实践中它不会给你带来很多,因为数据不太可能重复。
答案 6 :(得分:0)
我不同意戴夫。多对多方法(地址< - >用户)既安全又极具优势。
当客户移动时,地址表中的地址不会更改。相反,新地址位于地址表中,客户等链接到该记录。如果表中尚未包含新地址,则会将其添加到表中。
地址记录本身是否会发生变化?是的,在这样的情况下:
在这种情况下,将所有地址放在一个表中而不重复会得到回报;任何其他安排都需要烦人且重复的数据录入。
当然,如果数据库被滥用,那么避免多对多关系会更安全。但是,通过这个标记,如果数据库处于糟糕的状态,最好只打印出所有内容,将其存储在文件柜中,并根据纸质副本验证每个事务。因此,在我看来,“防止滥用”并不是一个好的设计原则。