CON CONTROLLA AGGIUNGI VINCITORE seguito da CONTROLLA VINCERE vs AGGIUNGI VINCITORE

Sto esaminando il database di esempio AdventureWorks per SQL Server 2008 e vedo nei loro script di creazione che tendono a utilizzare quanto segue:

ALTER TABLE [Production].[ProductCostHistory] WITH CHECK ADD 
CONSTRAINT [FK_ProductCostHistory_Product_ProductID] FOREIGN KEY([ProductID])
  REFERENCES [Production].[Product] ([ProductID])
GO

seguito immediatamente da:

ALTER TABLE [Production].[ProductCostHistory] CHECK CONSTRAINT     
[FK_ProductCostHistory_Product_ProductID]
GO

Vedo questo per chiavi esterne (come qui), vincoli univoci e CHECKvincoli regolari ; DEFAULTi vincoli utilizzano il formato normale con cui ho più familiarità come:

ALTER TABLE [Production].[ProductCostHistory] ADD  CONSTRAINT  
[DF_ProductCostHistory_ModifiedDate]  DEFAULT (getdate()) FOR [ModifiedDate]
GO

Qual è la differenza, se esiste, tra farlo nel primo modo rispetto al secondo?

La prima sintassi è ridondante: WITH CHECK è predefinito per i nuovi vincoli e anche il vincolo è attivato per impostazione predefinita.

Questa sintassi viene generata dallo studio di gestione SQL durante la generazione di script sql: suppongo sia una sorta di ridondanza aggiuntiva, probabilmente per garantire che il vincolo sia abilitato anche se viene modificato il comportamento del vincolo predefinito per una tabella.

Per dimostrare come funziona--

CREATE TABLE T1 (ID INT NOT NULL, SomeVal CHAR(1));
ALTER TABLE T1 ADD CONSTRAINT [PK_ID] PRIMARY KEY CLUSTERED (ID);

CREATE TABLE T2 (FKID INT, SomeOtherVal CHAR(2));

INSERT T1 (ID, SomeVal) SELECT 1, 'A';
INSERT T1 (ID, SomeVal) SELECT 2, 'B';

INSERT T2 (FKID, SomeOtherVal) SELECT 1, 'A1';
INSERT T2 (FKID, SomeOtherVal) SELECT 1, 'A2';
INSERT T2 (FKID, SomeOtherVal) SELECT 2, 'B1';
INSERT T2 (FKID, SomeOtherVal) SELECT 2, 'B2';
INSERT T2 (FKID, SomeOtherVal) SELECT 3, 'C1';  --orphan
INSERT T2 (FKID, SomeOtherVal) SELECT 3, 'C2';  --orphan

--Add the FK CONSTRAINT will fail because of existing orphaned records
ALTER TABLE T2 ADD CONSTRAINT FK_T2_T1 FOREIGN KEY (FKID) REFERENCES T1 (ID);   --fails

--Same as ADD above, but explicitly states the intent to CHECK the FK values before creating the CONSTRAINT
ALTER TABLE T2 WITH CHECK ADD CONSTRAINT FK_T2_T1 FOREIGN KEY (FKID) REFERENCES T1 (ID);    --fails

--Add the CONSTRAINT without checking existing values
ALTER TABLE T2 WITH NOCHECK ADD CONSTRAINT FK_T2_T1 FOREIGN KEY (FKID) REFERENCES T1 (ID);  --succeeds
ALTER TABLE T2 CHECK CONSTRAINT FK_T2_T1;   --succeeds since the CONSTRAINT is attributed as NOCHECK

--Attempt to enable CONSTRAINT fails due to orphans
ALTER TABLE T2 WITH CHECK CHECK CONSTRAINT FK_T2_T1;    --fails

--Remove orphans
DELETE FROM T2 WHERE FKID NOT IN (SELECT ID FROM T1);

--Enabling the CONSTRAINT succeeds
ALTER TABLE T2 WITH CHECK CHECK CONSTRAINT FK_T2_T1;    --succeeds; orphans removed

--Clean up
DROP TABLE T2;
DROP TABLE T1;

A seguito di questi eccellenti commenti sui vincoli di fiducia:

select * from sys.foreign_keys where is_not_trusted = 1 ;
select * from sys.check_constraints where is_not_trusted = 1 ;

Un vincolo non attendibile, come suggerisce il nome, non può essere considerato attendibile per rappresentare con precisione lo stato dei dati nella tabella in questo momento. Tuttavia, può essere considerato attendibile per controllare i dati aggiunti e modificati in futuro.

Inoltre, l'ottimizzatore delle query non tiene conto dei vincoli non attendibili.

Il codice per abilitare i vincoli di controllo e i vincoli di chiave esterna è piuttosto male, con tre significati della parola "controllo".

ALTER TABLE [Production].[ProductCostHistory] 
WITH CHECK -- This means "Check the existing data in the table".
CHECK CONSTRAINT -- This means "enable the check or foreign key constraint".
[FK_ProductCostHistory_Product_ProductID] -- The name of the check or foreign key constraint, or "ALL".

WITH NOCHECK viene utilizzato anche quando in una tabella sono presenti dati che non sono conformi al vincolo definito e non si desidera che si verifichino i nuovi vincoli che si stanno implementando ...

WITH CHECK è in effetti il ​​comportamento predefinito, tuttavia è buona norma includere nella codifica.

Il comportamento alternativo è ovviamente da usare WITH NOCHECK, quindi è bene definire esplicitamente le tue intenzioni. Questo è spesso usato quando stai giocando / modificando / cambiando le partizioni in linea.

I vincoli di controllo e chiave esterna hanno il concetto di essere attendibili o non attendibili, nonché di essere abilitati e disabilitati. Vedere la pagina MSDN ALTER TABLEper i dettagli completi.

WITH CHECK è l'impostazione predefinita per l'aggiunta di una nuova chiave esterna e per controllare i vincoli, WITH NOCHECK è l'impostazione predefinita per la riattivazione della chiave esterna disabilitata e per i vincoli di verifica. È importante essere consapevoli della differenza.

Detto questo, tutte le dichiarazioni apparentemente ridondanti generate dalle utility sono semplicemente lì per sicurezza e / o facilità di codifica. Non preoccuparti per loro.

Ecco del codice che ho scritto per aiutarci a identificare e correggere VINCOLI non attendibili in un DATABASE. Genera il codice per risolvere ogni problema.

    ;WITH Untrusted (ConstraintType, ConstraintName, ConstraintTable, ParentTable, IsDisabled, IsNotForReplication, IsNotTrusted, RowIndex) AS
(
    SELECT 
        'Untrusted FOREIGN KEY' AS FKType
        , fk.name AS FKName
        , OBJECT_NAME( fk.parent_object_id) AS FKTableName
        , OBJECT_NAME( fk.referenced_object_id) AS PKTableName 
        , fk.is_disabled
        , fk.is_not_for_replication
        , fk.is_not_trusted
        , ROW_NUMBER() OVER (ORDER BY OBJECT_NAME( fk.parent_object_id), OBJECT_NAME( fk.referenced_object_id), fk.name) AS RowIndex
    FROM 
        sys.foreign_keys fk 
    WHERE 
        is_ms_shipped = 0 
        AND fk.is_not_trusted = 1       

    UNION ALL

    SELECT 
        'Untrusted CHECK' AS KType
        , cc.name AS CKName
        , OBJECT_NAME( cc.parent_object_id) AS CKTableName
        , NULL AS ParentTable
        , cc.is_disabled
        , cc.is_not_for_replication
        , cc.is_not_trusted
        , ROW_NUMBER() OVER (ORDER BY OBJECT_NAME( cc.parent_object_id), cc.name) AS RowIndex
    FROM 
        sys.check_constraints cc 
    WHERE 
        cc.is_ms_shipped = 0
        AND cc.is_not_trusted = 1

)
SELECT 
    u.ConstraintType
    , u.ConstraintName
    , u.ConstraintTable
    , u.ParentTable
    , u.IsDisabled
    , u.IsNotForReplication
    , u.IsNotTrusted
    , u.RowIndex
    , 'RAISERROR( ''Now CHECKing {%i of %i)--> %s ON TABLE %s'', 0, 1' 
        + ', ' + CAST( u.RowIndex AS VARCHAR(64))
        + ', ' + CAST( x.CommandCount AS VARCHAR(64))
        + ', ' + '''' + QUOTENAME( u.ConstraintName) + '''' 
        + ', ' + '''' + QUOTENAME( u.ConstraintTable) + '''' 
        + ') WITH NOWAIT;'
    + 'ALTER TABLE ' + QUOTENAME( u.ConstraintTable) + ' WITH CHECK CHECK CONSTRAINT ' + QUOTENAME( u.ConstraintName) + ';' AS FIX_SQL
FROM Untrusted u
CROSS APPLY (SELECT COUNT(*) AS CommandCount FROM Untrusted WHERE ConstraintType = u.ConstraintType) x
ORDER BY ConstraintType, ConstraintTable, ParentTable;