«Punir» les développeurs ou résoudre le problème automatiquement? Déclencheur vs contrainte

Question

Disons que j'ai une colonne de base de données qui doit toujours être en majuscule.

Voici quelques idées:

1) Créez une contrainte de colonne de: col = UPPER (col)

2) Créez un déclencheur de ligne avant insertion / mise à jour qui définit: col = UPPER (col)

Généralement, plus il y a de contraintes sur les données de votre base de données, mieux c'est, et les déclencheurs peuvent être mystérieux et néfastes. Supposons que les développeurs qui écrivent du code appartiennent à la même organisation et que nous puissions modifier le code qu’ils écrivent.

Quelle approche utiliseriez-vous et pourquoi?

Cela doit être en majuscule car les données en question sont en réalité toujours en majuscules (elles ont été imprimées de cette façon par divers tiers). Les lettres majuscules et minuscules n'ont pas de signification pour ce champ particulier.

Answer 1

Cela dépend de la raison pour laquelle la colonne doit être en majuscule, mais en général je choisirais la contrainte.

Je n'aime pas les choses qui changent mes données lorsque je les insère dans la base de données. Cela signifie que j'ai un décalage entre ce que j'ai écrit et ce que je vais lire la prochaine fois.

Si le texte a été saisi par un utilisateur, pensez à ajouter une colonne supplémentaire contenant la version majuscule. De cette façon, vous affichez toujours le texte tel que l'utilisateur l'a saisi

Answer 2

Dans la plupart des situations, je dirais (1), car comme vous l'avez fait remarquer, les déclencheurs peuvent souvent être mauvais / bizarres (mais pas toujours). Mais lorsque je traite de la sensibilité à la casse des cordes, j’ai tendance à considérer cela comme un cas particulier et à le régler à chaque étape du processus. Je ne suis pas sûr d’avoir des raisons concrètes de le faire, cela ne fait que "sentir". droite. Probablement parce que dans la plupart des environnements dans lesquels j'ai travaillé au moins, du point de vue de la logique métier, FoO est toujours égal à foo est toujours égal à FOO .

De plus, dans ce cas, il semble moins contraignant pour le développeur de dire "Pour info, toutes les chaînes sont stockées en majuscule sur le serveur". que de se taper le poignet chaque fois qu'ils oublient. Ce n'est pas comme si on disait "Pour votre information, chaque fois que vous insérez un prix dans la base de données, une taxe de vente sera ajoutée".

Answer 3

Ceci est mieux implémenté sous forme de contrainte, cela évite une charge supplémentaire et fait ce que vous voulez - forcez les données au format souhaité.

Je pense que la méthode utilisée pour forcer la conversion dans la base de données est fausse, car les données pouvant être converties sans perte d'intégrité doivent être gérées dans la couche base de données. Si le cas est insignifiant, traitez-le comme tel - et une contrainte vous aidera à intercepter les erreurs.

L'ajout d'un index non sensible à la casse est peut-être une meilleure solution (voir index insensible à la casse de la base de données ).

Answer 4

Ou augmentez la couverture des tests automatisés et évitez toute charge supplémentaire sur le serveur de production.

Answer 5

J'envisagerais également une autre approche: fournir un "API de table". cela permet aux développeurs de simplement transmettre des valeurs à une procédure stockée (ou autre), ce qui garantit ensuite que les valeurs sont en majuscule lors de l'insertion (selon votre exemple). Je voudrais également sauvegarder cela avec une contrainte (cela peut faciliter l'optimisation des requêtes) et supprimer les privilèges de changement direct sur la table - si vous ne faites pas confiance aux développeurs pour mettre toutes les insertions en majuscule, alors vous ne devriez pas leur faire confiance. utilisez toujours le TAPI non plus.

Answer 6

SI vous pouvez faire quelque chose dans une contrainte de colonne sur la base de données plutôt que sur un déclencheur, il est généralement préférable, car il est souvent plus rapide. Si vous parlez de faire appliquer l'application, je ne le recommande pas. Si la règle doit toujours s'appliquer, elle ne devrait jamais être ailleurs que dans la base de données. Des éléments autres que l'application pour laquelle vous écrivez du code peuvent modifier les données d'une base de données. L’intégrité des données est la responsabilité de la base de données, conservez le code où il appartient pour éviter les problèmes.