小编use*_*379的帖子

不使用 FK 约束是我公司的不为人知的规则。FK 约束仅在设计 ERD 时使用，在创建表时不使用。

据我的前辈说，在实际操作中，当我们处理紧急问题时，这些都是非常耗时的障碍。他说，当我们需要立即使用 INSERT/UPDATE/DELETE 语句时，约束会阻止这些语句的执行，并且在保持约束的同时编写语句也很耗时。我什至听说许多其他公司也在这样做。

虽然我有点理解这些挣扎，但我不确定这是否是一个好方法，因为它与我对 DB 的理解完全相反。这家公司也是我的第一份工作，所以我不知道其他公司是如何处理的。

实际上，您对此有何看法？这有道理吗？有更好的方法吗？其他公司在这方面的表现如何？

更新：对于韩国公司来说，这似乎是一种很常见的方法。我问了几个在别的公司工作的前辈，他们大多都说都是这样。甚至其中一个人在一家金融公司工作！有趣的...

我目前正在设计一个事务表。我意识到需要计算每一行的运行总数，这可能会降低性能。所以我创建了一个包含 100 万行的表用于测试。

CREATE TABLE [dbo].[Table_1](
    [seq] [int] IDENTITY(1,1) NOT NULL,
    [value] [bigint] NOT NULL,
 CONSTRAINT [PK_Table_1] PRIMARY KEY CLUSTERED 
(
    [seq] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

我试图获取最近的 10 行及其运行总数，但花了大约 10 秒。

--1st attempt
SELECT TOP 10 seq
    ,value
    ,sum(value) OVER (ORDER BY seq) total
FROM Table_1
ORDER BY seq DESC

--(10 rows affected)
--Table 'Worktable'. Scan count 1000001, logical reads 8461526, …

我改变了这个查询

SELECT ...
FROM linkedServer.DB.Schema.Table1 t1
LEFT JOIN linkedServer.DB.Schema.Table2 t2 ON t1.ORDER_ID = t2.ORDER_ID
WHERE t1.BRANCH_ID NOT IN (
        '009991', '009992', '009993', '009994', '009995', '009996', '009999', '900001', 
        '900002', '900003', '900004', '900005', '900006', '900007', '900008', '999991', 
        '999992', '999993', '999994', '999995'
        )
GROUP BY ...

进入这个

SELECT ...
FROM linkedServer.DB.Schema.Table1 t1
LEFT JOIN linkedServer.DB.Schema.Table2 t2 ON t1.ORDER_ID = t2.ORDER_ID
WHERE t1.BRANCH_ID NOT IN (
        SELECT b.BRANCH_ID
        FROM TB_BRANCH b --25 rows in total
        WHERE b.START_DT = '99999999' --the result of this sub-query …