Question

JOIN语句中使用的SELECT子句与两个表如何相互关联，即一对多，多对一，一对一之间是否存在关系？如果没有，可以/应该在SQL代码中定义这些类型的表关系吗？

Answer 1

这里有几个问题：

SELECT语句中使用的JOIN子句与两个表之间的关系是否存在关联？

在绝大多数情况下，是的，JOIN子句将说明两个表彼此相关的方式之一。但情况并非总是如此。请考虑以下两个示例：

1）

Select  *
From    TableA  A
Join    TableB  B   On  A.B_Id = B.Id

2）

Select  *
From    TableA      A
Join    @CodeList   B   On  A.Code = B.Code

在第一个示例JOIN中，TableA和TableB之间的表格中存在已定义的关系。

但是，在第二个示例中，@CodeList更有可能更多地充当TableA的过滤器。在这种情况下，JOIN不是在两个表之间定义的关系，而是一种将数据过滤到定义的集合的方法。

所以回答你的第一个问题：JOIN通常表明两个表之间存在某种关系，但它的存在本身并不总是意味着。

可以/应该在SQL代码中定义这些类型的表关系吗？

不一定。即使折扣上述示例，JOIN条件的表之间没有预期关系，也不总是需要定义FOREIGN KEY关系。使用FOREIGN KEY CONSTRAINTS时要记住的一件事是 CONSTRAINTS 。

根据您的需要，您是否希望物理约束数据以不允许违反约束的值完全是情境化的。

可以吗？是的，他们当然可以。

应该他们？并不总是 - 这取决于你的意图。

Answer 2

您不需要具有正式的PK / FK关系来编写联接。但是，如果您有这些类型的关系，那么从数据完整性视图中正式化它们符合您的最佳利益。此外，当您已经拥有这些关系时，SQL Server可以为查询创建更好的执行计划。见https://msdn.microsoft.com/en-us/library/ff647793.aspx

不创建PK / FK关系没有任何好处。

Answer 3

使用外键来定义这些关系。这些密钥通过在任何一方强制执行约束来确保参照完整性。

示例：

table-one: id, name table-many: id, name, table-one_id

这里，table-one_id是一个外键（引用表一的id），确保你只能输入有效的id（存在于表一中）。

定义FK不是强制性的，但它提供了参照完整性。

SELECT语句中的JOIN通常使用这些外键完成。但这在技术上并不需要或不需要。

JOIN和一对多类型关系是否相关？

3 个答案: