我有一个方案，其中： 有两个（或多个）表代表独立项目。可以说用户和公司与许多表相关的一对多关系
这两个表都需要存储地址。每个人可以有一个或多个地址
在正常的1到很多情况下地址表woudl只是有一个UserId或一个CompanyId创建一个正常的1对多关系。
在这种情况下，我有我能想到的
地址表可以同时拥有一个用户名和一个CompanyId几个办法，只有一个将用于每个记录。
2键可以使用的ObjectId和对象类型因此对象ID将有一个用户ID或CompanyId和对象类型woudl是用户或公司
创建ObjectTable并添加到的ObjectId用户和公司。地址然后将有一个OjbectId
我真的不喜欢任何这些解决方案。我想知道这里最好的方法是什么。
在另一个说明我很可能用户linqtosql我的数据访问层。
我不确定有关Linq-to-SQL的含义，但解决此问题的一种模式是使用多个Junction Tables。
对于您的情况，您将有一个名为AddressUsers的表，它具有两列：AddressId和UserID以及一个名为AddressCompanies的表，其中具有AddressId和CompanyId列。
去许多一对多：
地址表，具有独特的合成ID（例如，自动增量）。
user_address表，具有唯一的合成id（例如，自动增量），user_id外键和地址外键。
一个company_address表，具有唯一的合成id（例如，自动增量），company_id外键和地址外键。
（请注意，如果用户（或公司）可能有只有一个地址，你就必须在user表中的ADDRESS_ID外键（或德公司表），这是不是你的使用情况。）
你有什么是多态关联。我不熟悉linqtosql，但是如果它支持这种类型的关系的参照完整性，那么不要害怕，要做任何地图。
在标准实践中，多态关联通常可以通过反转来克服。您应该为每个用户和公司分别添加一个路口（路口）表，以将它们加入地址。这类似于多对多关系，交集表中的每一行都指一个用户和一个地址。
如果使用交集表，为了避免多对多（但保持一对多）在交集表中的地址关键字上设置唯一约束。
如果您有ORM问题，请使用与UserAddress和CompanyAddress结合的父地址表。
我推荐遵循tpdi的建议，但在用户/公司和地址之间使用一对多关系;至少您的所有关键数据类型都是相同的。
添加我的答案的主要原因是响应您的第二个建议，即存储ObjectID和ObjectType - 属性拆分是一个坏主意，请避免！
请仔细阅读以下Celel文章： http://www.tdan.com/view-featured-columns/9852