J'apprends SQL et je suis tombé sur la contrainte. Je peux les définir comme ceci: et comme ceci: Pourquoi je leur donne des noms? Ou pourquoi je devrais ou ne devrait-il pas leur donner des noms?
Comme je peux voir dans cet exemple et la plupart des situations dans mon esprit, je ne peux pas les réutiliser. Alors, quel est l'avantage de donner un nom à une contrainte?
6 Réponses :
Vous ne spécifiez pas SGBDM. Les points suivants s'appliquent à SQL Server et je suppose que d'autres RDBMS sont également très probables.
Vous devez connaître le nom de la contrainte à goutte . Le nom de la contrainte apparaît dans les messages d'erreur de violation des contraintes afin de donner un nom explicite peut rendre cela plus significatif (SQL Server sera auto Générez un nom pour la contrainte qui ne vous indique rien de l'intention de la contrainte).
Il existe des avantages significatifs de donner des noms explicites à vos contraintes. Quelques exemples:
Contraintes comme objet dans SQL, de la même manière qu'un PK, FK, Table ou presque autre chose est. Si vous donnez un nom de contrainte, vous pouvez facilement le laisser tomber si nécessaire, dites par exemple lors d'une sorte d'importation de données en vrac. Si vous ne lui donnez pas de nom, vous pouvez toujours le laisser tomber, mais vous devez découvrir le nom auto-organisé que SQL le donnera.
Si votre contrainte est violée, le nom du message d'erreur permet de le déboguer et de présenter le message d'erreur à l'utilisateur.
Il semble que vous utilisiez PostgreSQL et la différence n'est pas vraiment si grande.
En effet, un nom généré par un système dans PostgreSQL est en fait un peu significatif. Mais "positif_price" est toujours plus facile à comprendre que "foo_price_check":
Pensez à quel message d'erreur est préférable de comprendre:
Nouvelle ligne pour la relation "FOO" viole la contrainte de contrôle "FOO_Price_Check"
ou
Nouvelle ligne pour la relation "FOO" enfreint la contrainte de vérification "POSITIVE_PRICE"
Dans Oracle, cela est encore pire car un système généré ne contient pas aucun indice sur ce qui n'allait pas:
ORA-02290: Contrainte de contrôle (SYS_C0024109) violé
vs.
ORA-02290: Vérifier la contrainte (positif_price) violé
SQL Server est quelque part au milieu, mais souffre un peu du même problème que Oracle.
La contrainte nommée a des scénarios où ils sont vraiment utiles. Voici ceux que j'ai rencontrés jusqu'à présent:
Si vous avez besoin de comparer Environnement comme Dev et UT pour voir les différences, vous pouvez avoir des "faux potentiels" sur le niveau de table qui est vraiment ennuyeux. La définition de la table est littéralement la même, mais comme le nom autogogenéré est différent, il est marqué comme changement.
Oui, certains outils permettent de sauter / ignorer le nom de la contrainte, mais pas tous.
Si vous utilisez des outils pour un outil de migration basé sur l'état comme MS SSDT, puis vous examinez manuellement les modifications générées avant de les appliquer sur la production, vous souhaitez que votre script final soit aussi court que possible.
Avoir une centaine de lignes, qui dépose la contrainte de goutte et la crée avec un nom différent est "bruit". Une certaine contrainte pourrait être désactivée à partir de cet outil, certaines sont régénérées (par défaut / chèque). Ayant un nom explicite et une bonne convention de dénomination le résout pour tous.
dernier, mais non le moindre. Être explicite simplifie les choses. Si vous avez un nom explicite, vous pouvez renvoyer cet objet de base de données sans rechercher des vues système / métadonnées.