1
Note: Cette question n'est pas liée à Visual Paradigm. Toute personne qui connaît SQL pourrait y répondre. J'utilise Visual Paradigm pour modéliser une base de données dans notre projet (en utilisant des diagrammes ER). Lorsque Visual Paradigm génère l'équivalent SQL pour la base de données et que je l'importe dans MSSQL, cela fonctionne plutôt bien.Contraintes étranges dans le SQL généré
J'ai regardé dans le code généré SQL pour vous assurer que tout est bien et j'ai vu quelque chose d'étrange !:
Pour tblContracts je définissais une contrainte nommée EndAfterStart pour vous assurer que la valeur de endDate est toujours plus grand que startDate. Le code SQL généré pour cette contrainte est ici:
IF NOT EXISTS (SELECT * FROM sys.check_constraints WHERE object_id=OBJECT_ID(N'[dbo].[EndAfterStart]'))
ALTER TABLE [dbo].[tblContracts] WITH CHECK ADD CONSTRAINT [EndAfterStart] CHECK (([startDate]<=[endDate]))
GO
ALTER TABLE [dbo].[tblContracts] CHECK CONSTRAINT [EndAfterStart]
GO
Et les questions suivantes:
- Pourquoi
tblContractsest modifié deux fois pour ajouter cette contrainte ?! - Les deux premières lignes ne sont-elles pas suffisantes?
- Quelle est la différence entre la deuxième ligne et la quatrième ligne?
@Constantin - Vous avez raison. mais quand j'omets la Quatrième ligne, la table créée a aussi la contrainte activée. Il semble dans le SQL généré, les contraintes sont activées explicitement, même si elle est déjà activée ou non. – Isaac
Je suppose que le script a été conçu pour convenir à la création de contraintes ainsi que pour «remettre en forme le schéma de la base de données». Pour une raison quelconque, les auteurs ont préféré ne pas mettre la 4ème ligne dans la clause 'else'. – Constantin