SQL Server Check/NoCheck differenza negli script generati

Sto provando a sincronizzare gli schemi tra diversi database. Fondamentalmente, ho eseguito le attività-> Genera script con SQL Server Management Studio (2005) su entrambi i database e sto confrontando l'output con uno strumento diff.SQL Server Check/NoCheck differenza negli script generati

Per qualche ragione, uno script aggiunge il vincolo WITH CHECK e uno con nessun controllo, seguita da entrambi i vincoli di essere riattivato.

I per il primo database ottengo:

ALTER TABLE [dbo].[Profile] WITH CHECK ADD CONSTRAINT [FK_Profile_OrganizationID] FOREIGN KEY([OrganizationID]) 
REFERENCES [dbo].[Organization] ([OrganizationID]) 
GO 
ALTER TABLE [dbo].[Profile] CHECK CONSTRAINT [FK_Profile_OrganizationID] 
GO

La seconda banca dati genera come

ALTER TABLE [dbo].[Profile] WITH NOCHECK ADD CONSTRAINT [FK_Profile_OrganizationID] FOREIGN KEY([OrganizationID]) 
REFERENCES [dbo].[Organization] ([OrganizationID]) 
GO 
ALTER TABLE [dbo].[Profile] CHECK CONSTRAINT [FK_Profile_OrganizationID] 
GO

Così ho due domande:

è il risultato alla fine lo stesso ? (Edit: Sembra che un sacco di persone stanno raccogliendo solo sulla prima esposizione dei due script Sono interessato nel risultato finale della totalità di entrambi gli script..)
Se alla fine il risultato è lo stesso, perché Management Studio li genera in modo diverso per diversi database?

fonte

2009-08-26 Nathan

Il risultato finale non è lo stesso!

SQL Server non si fida dell'unicità dell'FK in quanto non è selezionato. Ciò significa che è necessaria un'ulteriore elaborazione se si utilizza la colonna in una query.
Per farla breve è necessario che SQL Server controlli la colonna in modo che venga considerata attendibile.

Per quanto riguarda il motivo per cui sono diversi da server diversi, controllare la colonna isnottrusted in sys.foreign_keys. Ciò potrebbe influire su ciò che sta generando SSMS?

Per ulteriori informazioni su questo, controllare my other answer relativo a FK & NO CHECK/CHECK options.

fonte

2009-08-27 02:29:10

Tuttavia, se si guardano i due script di script, immediatamente dopo aver aggiunto il vincolo, c'è ALTER TABLE [ dbo]. [Profilo] CONTROLLA CONSTRAINT [FK_Profile_OrganizationID] GO Non controlla i vincoli in quel punto? – Nathan

Per quanto riguarda la seconda parte della risposta, si è effettivamente corretto che is_not_trusted sia impostato su uno dei database e non sull'altro. Che effetto ha questo? – Nathan

Trovato questo articolo: http://sqlblog.com/blogs/tibor_karaszi/archive/2008/01/12/non-trusted-constraints.aspx Quindi sembra che la seconda istruzione nel batch si accerti solo che il vincolo sia abilitato, in realtà non controlla i dati esistenti. Per verificare effettivamente i dati esistenti, ho bisogno di ALTER TABLE? CON CHECK CHECK CONSTRAINT all – Nathan

Sì, i due script sono diversi

CON CONTROLLO controllerà i dati esistenti contro il nuovo vincolo.
WITH NOCHECK non verificherà i dati esistenti rispetto al nuovo vincolo. Ciò ti consentirà di avere record figli senza un genitore corrispondente.

EDIT: Per quanto riguarda il motivo per cui SSMS sta facendo questo non ho idea di

fonte

2009-08-27 01:28:41 Cory

Tuttavia, se si guardano i due script di script, subito dopo aver aggiunto il vincolo, c'è ALTER TABLE [dbo]. [Profilo] CONTROLLA CONSTRAINT [FK_Profile_OrganizationID] GO Non controlla i vincoli in quel punto? – Nathan

Entrambi sono SQL Server 2005 server? Poiché il risultato è lo stesso, lo strumento di generazione del codice può utilizzare routine diverse basate su diverse versioni del prodotto

fonte

2009-08-27 01:51:15 Rodrigo

In realtà, in questo particolare momento, entrambi i database si trovano sullo stesso server, quindi non ci sono sicuramente differenze di versione di Sql Server – Nathan

SQL Server Check/NoCheck differenza negli script generati

risposta

Problemi correlati