数据库模式所需的设计模式，其中两个类都构成第三个类

Question

考虑一个既有字母又有人类的系统;这两个类都构成一个地址。在为系统设计数据库时，为地址设置单独的模式似乎是明智的，但这会导致问题;我不知道如何在地址表中清楚地识别它所属的外键，因为外键可以识别字母或人。我还希望能够添加更多的类，这些类也将组成一个地址。

我很感激解决这种设计点的设计模式。

最好的问候

Answer 1

  

我不知道如何拥有外键   在地址表中清楚地识别   它属于什么，因为外国人   密钥可以识别一个字母或   一个人。

听起来你有错误的方法。地址表中没有外键;相反，letters表有一个引用地址表的外键，而person表也有一个引用地址表的外键。

在SQL中，Information Schema目录中的REFERENTIAL_CONSTRAINTS视图将告诉您哪些表引用了地址表。

在我们的商店，我们经常讨论地址是否应该作为一个实体建模。将地址视为实体的问题在于除了属性本身之外没有可靠的密钥（邮政编码，房屋名称或号码等），许多变体可以识别相同的地址（我可以用20种不同的方式写我的家庭地址） 。然后你需要考虑邮政信箱，地址护理，圣诞老人等。大问题：你是否允许修改地址？如果有人移动房屋，他们是否使用修改后的属性保持相同的地址实体（这样所有链接的实体都会更改地址）或者锁定地址的属性并强制创建新的地址实体然后重新链接所有引用地址到新的（并删除现在孤立的地址实体，如果是，那么你为什么还要替换它？？）但是你的应用程序仍然需要修改地址以防邮局改变它在现实生活中，但如何防止这种能力被滥用，即将其用于上述违法的房屋搬迁？您可以使用Web服务来清理您的地址数据，这是正确的，但外部系统方式的数据不太干净，因此您无法再使地址实体匹配......？

我喜欢保持简单：地址是一个单一属性，是您必须放在邮件项目上的明文，以便邮局将邮件传递给相关的可寻址实体;它本身不是一个实体，因为它缺少一个标识符。出于实际原因（例如能够在地址标签上打印），这个单一属性通常被分成亚原子元素（address_line_1，address_line_2，... postal_code，等等）。

由于大多数SQL产品都缺乏对域的支持，因此对于为可寻址实体建模的每个表之间重复列名，数据类型，约束等没有问题。

Answer 2

当然外键应该来自引用地址表上主键的Letter和People表吗？

因此，Letter表包含一个AddressId列，引用Address表上的Id，Person表以及组成地址的任何后续类。

如果信件和人员组成多个地址，则需要中间链接表。