Vous n'êtes pas identifié(e).
Salut forumers,
Je dois stocker des constraints sous forme de texte puis les appliquer; le PB c'est que je ne trouve pas comment faire pour certaines.
Voila ce que je stocke par exemple:
1 | ^(1|2)\d{2}[0-1][0-2]([0][1-9]|[1-8][0-9]|[1-9]([0-7]|9)|[2][A-B])([0][0][1-9]|[0][1-9][0-9]|[1-9][0-9][0-9])([0][0][1-9]|[0][1-9][0-9]|[1-9][0-9][0-9])$Qui fonctionne farpaitement:
SELECT '199112B008403' ~ (SELECT const FROM tst WHERE id=1);
?column?
----------
t
(1 row)Par contre ça fait un paquet d'heures que je bute sur ce type de constraint:
2 | CHECK(char_length(VALUE) = 13)Qui me renvoie systématiquement FALSE:
SELECT '1234567890123' ~ (SELECT const FROM tst WHERE id=2);;
?column?
----------
f
(1 row)Ça m'étonnerait que ça ne soit pas possible, mais je dois louper un truc qq part et/ou taper bien à côté de la plaque (mais pas encore dans les gamelles:)
JY
Hors ligne
Pourquoi ne pas utiliser de vraies contraintes d'intégrité ? Je ne vois pas bien l'intérêt de stocker la contrainte dans une table de l'application, quand une table système est faite pour ça. C'est quoi la raison ?
Marc.
Hors ligne
Tout simplement parce que cela fait partie d'un système d'ajouts de champs à la DB.
Étant donné que toutes les valeurs des champs ajoutés se retrouvent dans une seule table, en dehors du NOT NULL (implicite, puisque NULL == absence de row dans la table), on ne peut préjuger des contraintes applicables, d'où l'externalisation desdites contraintes.
Hors ligne
L'idée, c'est que pour ne pas rajouter de colonnes aux bons endroits (dans les bonnes tables), vous définissez quelque chose à la attribut/clé/valeur dans une autre table ?
Marc.
Hors ligne
Ouii: une table des tables, une pour les caractéristiques de la colonne ajoutée et une pour toutes les données de toutes les colonnes ajoutées (+ les index qui vont bien, oeuf corse.)
L'intérêt de ce système n'est bien évidemment pas de pouvoir modifier la DB à volonté, mais de l'utiliser pour personnaliser certaines colonnes, ou plutôt internationaliser certaines colonnes peu utilisées - eg: N° d'identification salarié (fr: SS), N° d'identification entreprise (fr: SIREN/SIRET), etc. - sans avoir à modifier les tables de base qui ne contiennent que les colonnes communes à tous les pays.
Hors ligne
Dans ce cas utilisez soit un trigger, soit une UDF lié avec contraintes CHECK.
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Oops: Qu'est-ce qu'une UDF?
Pour le trigger, je ne vois toujours pas quelle string de CHECK stocker 
Hors ligne
Arf, je n'avais pas vu la signature, mais le pseudo me disait qq chose!
En fait, c'est pour une implémentation (simplifiée) de ton papier sur les méta-données (sur developpez.net.)
Hors ligne
UDF == User Defined Function
Guillaume.
Hors ligne
Ha, Ok, merci.
Hors ligne
Bonne chance pour les performances, par contre. Il y a de bonnes raisons pour laquelle les SGBD stockent la plupart du temps les colonnes d'un enregistrement ensemble.
Dernière modification par Marc Cousin (20/06/2011 09:17:38)
Marc.
Hors ligne
Pour les récriminations voir SQLpro et son article: http://sqlpro.developpez.com/cours/mode … tadonnees/; en général j'ai pu constater qu'il sait ce qu'il dit...
Hors ligne
La technique des métadonnées fonctionne, mais pas sur de gros volumes de données. Pour stocker quelques paramètres d'une application (100-1000 lignes peut-être), c'est parfait. Pour les traitements métier d'une application importante, c'est très fortement déconseillé (vu des applications complètement inutilisables à cause de cela).
Après, c'est vous qui voyez en fonction de vos besoins, et de vos contraintes.
La cause de cela, à mon avis, c'est qu'on peut difficilement concilier flexibilité extrème du modèle de données (laisser l'utilisateur ajouter des colonnes au besoin...), performances, robustesse, facilité de développement (utiliser une base de données pour éviter d'écrire votre système de stockage à la main). Il faut savoir quels paramètres privilégier, et dans le cas de l'utilisation d'un SGBDR, on a déjà la robustesse, la facilité de développement.
Bon courage.
(on peut peut-être en rester là sur le hors sujet, non?)
Hors ligne