Respect de format

Bonjour.
Je suis en train de créer une table qui contient une clé primaire id de type varchar2(10). id est une série de lettres majuscules (au minimum 3) suivie de 2 chiffres indiquant une année.
Comment s'assurer au moment d'insérer des données dans un script SQL que id respecte le bon format et interrompre le script sinon ?
(Je suis débutant en SQL.)
Merci.

Bonjour,


Vous pouvez ajouter une contrainte CHECK dans la définition de votre table.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

DROP TABLE MYTABLE; CREATE TABLE MYTABLE ( id VARCHAR2(10) . . /* suivi par les autres colonnes définies dans votre table */ . );   ALTER TABLE MYTABLE ADD CONSTRAINT PK_MYTABLE PRIMARY KEY(id);   ALTER TABLE MYTABLE ADD CONSTRAINT CK_ID_MYTABLE CHECK (REGEXP_LIKE(id, '^([[:UPPER:]]{3})+[[:digit:]]{2}$'));

---

Cordialement,
Dariyoosh

Il ne faut pas mélanger plusieurs informations dans une même colonne, c'est ce qu'on appelle l'atomicité des données et ça fait partie de la première forme normale (1NF) de la modélisation des bases de données.

De plus, stocker l'année sur deux chiffres, vous n'avez jamais entendu parler du bogue de l'an 2000 ?

Je vous conseille plutôt d'avoir une colonne qui contiendra la partie texte de votre clef, une autre colonne qui contiendra une date (ou au pire une année, mais une date c'est mieux), de faire la clef primaire sur ces deux colonnes et de créer votre référence à partir de ces deux colonnes, soit en utilisant une vue, soit si vous êtes en 11g en créant une colonne calculée.

Bof, moi les clé primaires doubles en dehors des pures tables de relations, je suis assez contre. Parceque précisément il faut se palucher de la double identification partout et lorsqu'on fait par exemple une relation de 2 entités à doubles clés primaires, ça fait une table avec une clé sur 4 colonnes.

Ce qu'il faut éviter au maximum aussi, c'est de faire porter de l'information dans une clé primaire. Un identifiant ne doit vouloir rien dire, ça évite plus tard les désagréments, lorsque l'information change, de changer l'identifiant avec toutes les conséquences que ça a (tables de relations, clés étrangère etc, etc...)

Si les 2 chiffres correspondants à l'année ne servent qu'à créer un code unique et que cette information "année" n'est jamais prise dans cette colonne identificatrice, alors c'est pas trop grave.

Quand je dis jamais, c'est jamais de chez jamais. Ca veut dire que l'information "année de création" est stockée dans une autre colonne, et que, si plus tard il faut faire un correctif de cette donnée pour une raison x ou y, alors tu ne touches pas à la colonne clef primaire.

L'idée c'est que si y'a un monsieur qui habite à coté d'un pont, et qu'on a nommé pour ça "monsieur Dupont", le jour ou il déménage et habite à coté d'un puis, il ne s'appellera pas pour autan "monsieur Dupuis" il continuera à s'appeler "Dupont" tant pis si ça correspond plus à rien...

En revanche, si tu comptes te servir plus tard de cette information portée par ta clé, alors effectivement, c'est très périlleux. Dans ce cas, j'irais plus loin que Walace, et je crois qu'il faut que tu te débrouille à faire un identifiant unique, unique à travers les années. Cet identifiant sera ta clé primaire et tu mettre l'info "Année" dans une colonne à coté. Ainsi, les données seront proprement rangées et tu gardera le coté pratique de n'avoir ta clé primaire que sur une colonne.

Bonsoir et merci pour vos réponses.
En fait, je n'ai pas le choix pour le format de l'identifiant.
C'est un exercice et ce format est imposé.
Ta méthode, dariyoosh, marche très bien (au début, j'ai utilisé un trigger avec la fonction owa_pattern.match, mais c'est beaucoup mieux d'ajouter une contrainte).
Cette méthode, elle est compatible avec toutes les versions d'Oracle (à partir de 10.g) ?