Différence SQL Check Check/NoCheck dans les scripts générés

J'essaie de synchroniser les schémas entre différentes bases de données. Fondamentalement, j'ai exécuté des tâches -> Générer des scripts avec SQL Server Management Studio (2005) sur les deux bases de données et je compare la sortie avec un outil de diff.Différence SQL Check Check/NoCheck dans les scripts générés

Pour une raison quelconque, un script ajoute la contrainte AVEC CONTRÔLE et un SANS CONTROLE, suivi par les deux contraintes étant réactivée.

I pour la première base de données je reçois:

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 seconde base de données génère comme

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

J'ai donc deux questions:

est le résultat final de la même ? (Edit: Il semble que beaucoup de gens ramassent uniquement la première déclaration des deux scripts que je suis intéressé par le résultat final de l'ensemble des deux scripts..)
Si la fin Le résultat est le même, pourquoi Management Studio les génère-t-il différemment pour différentes bases de données?

Source

2009-08-26 Nathan

Le résultat final n'est pas le même! SQL Server ne fera pas confiance à l'unicité du FK car il n'est pas vérifié. Cela signifie qu'un traitement supplémentaire est requis si vous utilisez la colonne dans une requête.
Longue histoire courte est que vous devriez obtenir SQL Server pour vérifier la colonne de sorte qu'il est considéré comme approuvé.

En ce qui concerne les différences entre différents serveurs, consultez la colonne isnottrusted de sys.foreign_keys. Cela peut affecter ce que SSMS génère?

Pour plus d'une diatribe à ce sujet, vérifiez my other answer qui se rapporte à FK & AUCUNE option CHECK/CHECK.

Source

2009-08-27 02:29:10

Cependant, si vous regardez les deux scripts, immédiatement après l'ajout de la contrainte, il y a ALTER TABLE [ dbo]. [Profile] CHECK CONSTRAINT [FK_Profile_OrganizationID] GO Cela ne vérifie-t-il pas les contraintes à ce moment-là? – Nathan

En ce qui concerne la deuxième partie de votre réponse, vous avez en effet raison que is_not_trusted est défini sur l'une des bases de données, et non sur l'autre. Quel effet cela a-t-il? – Nathan

Trouvé cet article: http://sqlblog.com/blogs/tibor_karaszi/archive/2008/01/12/non-trusted-constraints.aspx Il semble donc que la deuxième déclaration dans le lot assure seulement que la contrainte est activée, il ne vérifie pas réellement les données existantes. Pour réellement vérifier les données existantes, je dois ALTER TABLE? AVEC CHECK CHECK CONSTRAINT tous – Nathan

Oui, ils les deux scripts sont différents

AVEC CONTRÔLE vérifiera les données existantes contre la nouvelle contrainte.
AVEC NOCHECK ne vérifie pas les données existantes par rapport à la nouvelle contrainte. Cela vous permettra d'avoir des enregistrements enfants sans parent correspondant.

EDIT: Quant à savoir pourquoi SSMS fait cela, je ne sais pas

Source

2009-08-27 01:28:41 Cory

Cependant, si vous examinez les scripts de scripts, immédiatement après l'ajout de la contrainte, ALTER TABLE [dbo]. [Profile] CHECK CONSTRAINT [FK_Profile_OrganizationID] GO Cela ne vérifie-t-il pas les contraintes à ce stade? – Nathan

Les deux sont des serveurs SQL Server 2005? Comme le résultat est le même, l'outil de génération de code peut-être utiliser différentes routines basées sur différentes versions du produit

Source

2009-08-27 01:51:15 Rodrigo

En fait, à ce moment précis, les deux bases de données sont sur le même serveur - donc il n'y a certainement pas de différences de version Sql Server – Nathan

Différence SQL Check Check/NoCheck dans les scripts générés

Répondre

Questions connexes