无需密钥即可加入?

发布于 2024-10-08 06:45:11 字数 72 浏览 0 评论 0原文

在 T-SQL (SQL Server 2008) 中,通过无键列(无关系) INNER JOIN 两个表在技术上是否正确?谢谢。

in T-SQL (SQL Server 2008), is it technically correct to INNER JOIN two tables through key-less columns (no relationships)? Thank you.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

时光瘦了 2024-10-15 06:45:12

是的。我经常绕过“中间”表加入子表的子表。

外键是数据完整性的约束:与查询制定无关。无论如何,除非您不关心数据质量和完整性,否则您应该拥有它们。

Yes. I often join child of a child table bypassing the "middle" table.

Foreign keys are constraint for data integrity: nothing to do with query formulation. You should have them anyway unless you don't care about data quality and integrity.

假装不在乎 2024-10-15 06:45:12

您可以连接具有相同数据的任意两个字段(并且它们也应该是相同的数据类型)。如果字段已编入索引,则除非您连接两个 varchar (4000) 字段,否则也不应该出现性能问题。当您的数据库设计不佳并且一列有多个用途时,您甚至可能需要执行此操作,特别是如果您使用了 EAV 模型。

然而,在这种情况下您将无法获得数据完整性。如果没有外键来强制执行规则,您可能会发现相关表的值与父表不匹配。这可能会导致在应该看到的查询中看不到记录或无法正确解释记录。因此,在适用的地方设置外键是一个很好的做法。

You can join on any two fields that have the same data (and they should be the same datatype as well). If the fields are indexed you should not have performance issues either unless you are joining on two varchar (4000) fields. You may even need to do this when you have a poor database design and one column is serving more than one purpose espcially if you have used an EAV model.

However what you won't get in this scenario is data integrity. Without a foreign key to enforce the rules, you may find that the related table has values that don't have a match to the parent table. This could result in records not seen in queries that should be seen or records which cannot be correctly interpreted. So it is a good practice to set up foreign keys where they are applicable.

巡山小妖精 2024-10-15 06:45:12

它会起作用,但可能不是很有效...如果可以的话,您绝对应该创建外键。

It will work, it might not be very efficient though...You should definitely create the foreign keys if you can.

2024-10-15 06:45:12

从技术上讲它会起作用。没有问题。但是,有时查询计划生成器会使用 FK 来帮助更好地利用索引。但是,从设计的角度来看,这并不是一个好主意。您应该尽可能多地使用 FK,特别是如果您想走 ORM 路线。

Technically it will work. No problems there.However, sometimes the query plan generator will use FK's to help make better use of indexes. But, from a design standpoint, it's not such a great idea. You should be using FK's as much as possible, especially if you want to go the ORM route.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文