Discussion :

[wafiwafi]

Merci à tous les intervenants qui ont laissé leurs empreintes de savoir dans lequel bien du monde piochera.
Si d'autres intervenants ont des idées sur le sujet; cela ne sera pas de refus.
Bien à vous tous

[fsmrel]

Bonsoir,

Au niveau conceptuel, le shéma est fabuleux
Il s'agit d'un shéma complêtement figé.
Voilà exactement l'exemple du MCD où de façon invariante on avancera que l'appli fonctionne, mais où malgrè moults arguments techniques, il est pauvre.

Merci de préciser quel est ce schéma qui ne trouve pas grâce à vos yeux. Si d’aventure c’est celui de vivicente, vous avez sans doute oublié qu’il débute dans la modélisation. Il ne vous est pas interdit de suivre l’exemple de CinePhil, qui n’hésite pas à montrer au débutant ce qui ne va pas, point par point, et comment apprendre à construire un MCD qui tienne la route (« Il aide, lui », Jean in Les Tontons flingueurs).

Et merci de respecter l’orthographe, vous ne facilitez pas la lecture.

Très pauvre, peu évolutif

Veuillez présenter les arguments vous permettant de pointer les défauts que vous relevez et ne pas vous contenter de dénigrer gratuitement. Présentez des solutions d’amélioration visant à l’enrichissement et à l’évolutivité du MCD.

aucune logique de composants

Que sont un composant ainsi qu’une logique de composants dans le contexte de l’élaboration de cette abstraction qu’est un MCD (Modèle Conceptuel de Données), objet de la discussion ? S’il s’agit des composants au sens UML (programme source, compilé, fichier de données, etc.) cet inventaire à la Prévert est hors sujet. C’est à la Direction de la Production informatique de l’entreprise de prendre ces choses en charge, en collaboration avec les équipes de développement. Un MCD ne traite que de l’univers du discours (l’entreprise).

d'un point de vue de conception pure, c'est une conception complêtement naïve

Encore une affirmation gratuite. Qu’est-ce qu’une conception pure ? Une conception naïve? Quel rapport existe-t-il entre ces deux concepts ?

Ca viole même une règle fondamentale de tout objet en ce bas monde : tout objet est amené à évoluer dans le temps.

Qu’est ce qu’un objet ?

1) Si un objet est quelque chose qui évolue qui dans le temps, alors c’est une variable au sens des langages de programmation, au même titre que la variable X, déclarée dans un programme P : au fil du temps, si X est par exemple du type entier, alors cette variable accueille successivement des valeurs qui sont des nombres entiers 1, 2, 3, etc. Ces nombres ne se situent ni dans le temps ni dans l’espace, mais on les fait apparaître par le truchement de X qui joue le rôle de médium.

2) Si un objet est une valeur, alors à l’instar d’un nombre entier il ne si situe ni dans le temps ni dans l’espace, c’est une constante et donc par définition il n’« évolue » pas.

A son tour, une entité-type E est une abstraction, en l’occurrence un type. Lors du passage au MLD (disons dans le cadre du Modèle Relationnel de Données), à cette entité-type on fera correspondre une variable relationnelle (relvar) E qui sera du type RELATION {A1 T1, A2 T2, ..., An Tn} (où Ai est un nom d’attribut et Ti le type de cet attribut) et qui prendra des valeurs de relations de ce type (relations pour abréger, êtres mathématiques fort intéressants qui bien entendu ne se situent ni dans le temps ni dans l’espace, puisque ce sont des constantes). Et bien entendu, le type RELATION {A1 T1, A2 T2, ..., An Tn} hérite de tous les opérateurs de l’algèbre relationnelle.

Là il n'y a aucune abstraction, aucun raisonnement objet, aucun raisonnement composant. C'est aussi en même temps la limite fondamentale de penser en relationnel.

Pour l’abstraction, voyez ce qui précède. Que vient faire ici le concept « objet » ? Celui de « composant » ? Qu’est-ce qu’un « raisonnement objet » ? Et, rebelote, un « raisonnement composant » ?

Quant au relationnel, c'est-à-dire la théorie relationnelle, commencez par l’étudier avant de parler de ses limites (à moins que vous ne soyez en mesure de les énumérer ici, de façon claire et objective). A toutes fins utiles, je vous renvoie à l’ouvrage de Date et Darwen : Databases, Types, and the Relational Model The Third Manifesto. Attention, il s’agit d’une étude très formelle, ramassée dans plus de 500 pages. Cela dit, que veut dire « penser en relationnel », sinon raisonner sur des ensembles (au sens de la théorie des ensembles), tant du point de vue structurel qu’algébrique ? Ou encore raisonner sur des prédicats, au moyen de la logique du 1er ordre et du calcul relationnel de tuples (ou de domaines) ?

je serai asssez intéressé de voir à quel MPD ce MCD correspond, est-ce du 1:1 ?

MPD est l’abréviation de « Modèle Physique des Données ». Le MPD traite de ce qui se passe dans la soute (organisation des espaces physiques, des index, etc.) Je suppose donc que vous avez voulu écrire « à quel MPD le MLD correspond » ou encore « à quel MLD ce MCD correspond ».

Dans le 1er cas, au nom de l’iindépendance physique, il n’y a pas de correspondance à établir entre les objets physiques et les entités mathématiques que sont le relations de la théorie relationnelle. Ainsi, entre une variable relationnelle (une table pour parler informellement) et un fichier il n’y a pas bijection : les relations (les valeurs prises par la variable relationnelle) peuvent être hébergées par plusieurs fichiers et un fichier peut héberger plusieurs relations de types différents. Cela reste sous le capot. De même, un n-uplet d’une relation n’a pas à correspondre à un enregistrement physique dans un fichier. Un n-uplet est lui aussi un être mathématique qui n’a pas à être contraint par l’organisation sous le capot. Ne cherchons pas à établir une quelconque correspondance entre la logique du 1er ordre et le fer à souder.

Dans le 2e cas, la production d’un MLD à partir d’un MCD est de préférence confiée à un AGL, mais elle est à vérifier et compléter par le DBA : opportunité de la mise en œuvre de variables relationnelles dans le cas des cardinalités 0,1 (notamment en ce qui concerne les associations-types réflexives), complétude des clés candidates d’une variable relationnelle, des dépendances fonctionnelles et multivaluées, des dépendances de jointure (y compris les dépendances de jointure généralisées), normalisation en cinquième forme normale (voire sixième dans le cas des données temporelles), définition des tables virtuelles (vues), définition des contraintes de base de données, de relation, d’attribut, de type. Etc. De même, certaines entités-types du MCD n’ont pas à faire l’objet de variables relationnelles, par exemple l’entité-type DATE qui ne fait que l’objet d’attributs de type DATE ou TIME, ou TIMESTAMP, etc. Quant à chercher une correspondance 1:1 entre un MCD et un MLD, on ne la trouvera pas, sauf peut-être dans des cas de figure simples.

Quant aux règles de gestion, là encore, une règle de gestion n'est pas nécessairement associée à 1 élément du modèle, mais peut l'être à n éléments et surtout à n événements, dont le pilotage peut potentiellement être délégué à un élément technique externe au stockage de données (architectures distribuées).

Qu’entendez-vous par « élément du modèle » ?

Par ailleurs, le pilotage des événements ne concerne pas le MCD (c'est-à-dire le QUOI), mais le MCT (c'est-à-dire le COMMENT, le QUAND, les conditions de déclenchement et toutes ces sortes de choses). Un MCD décrit l’univers su discours, c’est un ensemble de prédicats au sens de la logique du 1er ordre.

L’architecture distribuée est étrangère au sujet. Là encore, d’un point de vue MCD et MLD, on ne voit qu’un univers du discours pour le 1er, une base de données pour le 2e, même si dans ce 2e cas, d’un point de vue opérationnel, tout cela repose en fait, de façon transparente, sur plusieurs bases de données, gérées par plusieurs SGBD sur plusieurs machines. Encore une confusion des genres.

J'ai l'impression en fait qu'il y a confrontation de deux écoles :
- Ceux qui modélisent une base de données, donc MCD et MPD sont très liés, et le SQL est pris en compte dès le MCD
- Ceux qui définissent un domaine et ses objets, donc MCD et MPD sont lâches, et le MPD est la représentation technologique du MCD.

Quand on modélise un univers du discours (l'entreprise), il n’y a pas deux écoles. Chronologiquement, une fois que le SI a été urbanisé en [sous-]domaines, la direction de projet en partenariat avec la maîtrise d’œuvre (tant qu’à faire) produit un dossier de conception générale pour formaliser l’univers du discours avec un certain recul : pour chaque domaine (Référentiel Personnes, Contrats, Catalogue produits, etc.), on y trouve des MCD représentant les concepts, à grosse maille. Ensuite, à maille fine, toujours par [sous-]domaine, il y a production d’un dossier de conception détaillée dans lequel le MCD est muet quant au MLD et a plus forte raison quant au MPD. En ce qui concerne SQL, n’oublions pas que la direction de projet ignore tout de ce langage, ou à la longue, en a une idée plus ou moins précise, sans pour autant que cela vienne interférer avec la modélisation.

Par la suite, le concepteur du MCD et le DBA affecté au domaine (voire une équipe de DBA) ont un certain nombre d’entretiens avant que celui-ci ne produise le MLD (puis le MPD). Suite aux observations du DBA, le MCD utilisé pou la dérivation peut subir des modifications : révision des identifiants (qui ne doivent être composés que d’attributs artificiels ad-hoc, je vous renvoie une fois de plus à l’ouvrage de Tabourier, De l’autre côté de MERISE, page 81), typage des données, normalisation en BCNF, vérification des associations-types ternaires (et plus), pour voir si elles ne violent pas la quatrième forme normale, recherche des contraintes (notamment temporelles) qui peuvent être sous-traitées au SGBD, mise en œuvre des tables virtuelles (vues) en relation avec la spécialisation des entités-types, etc. Quant à prendre en compte le langage SQL quand débute la conception, c’est non. Ça n’est que lorsqu’on en arrive aux entretiens avec le DBA que celui-ci peut attirer l’attention sur les conséquences des choix de modélisation et ainsi faire réfléchir le directeur de projet qui peut revenir sur tel ou tel choix. Il arrive que certains aient la double casquette : concepteur et DBA, mais ça n’est pas pour autant qu’en tant que concepteur il faille s’adresser aux autres membres des équipes de conception en termes relationnels, tout en ayant en tête la théorie relationnelle qui permet d’éviter certaines erreurs de conception. A titre d’exemple, quand j’ai fait des remarques au débutant, je lui suggérais de normaliser en quatrième forme normale, mais sans le lui dire brutalement.

Quant à dire que le MPD (ou plutôt le MLD) « est la représentation technologique du MCD », c’est un peu court. Cette représentation « technologique » est à valider, évaluer à l’aune de la théorie relationnelle et la faire évoluer en conséquence.

Sur la lisibilité d'un modéle, là encore, c'est faisable si les domaines métiers traités sont triviaux. Il est normal que la complexité du métier (et donc non pas de description mais de ses événements et de ses workflows) influe sur le MCD.

Si le MCD complet comporte par exemple mille entités-types, la direction du projet aura pris la précaution d’urbaniser l’univers du discours en domaines (référentiels) sous-domaines et sous-sous-domaines, comme je l’ai déjà plus ou moins évoqué. Ainsi, on aura décomposé le projet en référentiels : Personnes, Contrats, Cotisations, Catalogue produits, Prospection de masse, Éditique, etc., peut-être une vingtaine, voire plus. Au niveau le plus fin, la représentation graphique doit tenir — de façon claire et lisible — sur un ensemble de pages au format (disons) A3, chaque page constituant une vue suffisante pour qu’un développeur n’ait pas à avoir sur son bureau un tombereau de diagrammes.

Quant aux événements (au sens fonctionnel), s’ils doivent eux aussi faire l’objet d’un domaine, pourquoi pas, mais si leur traitement peut être complexe, cela ne doit pas avoir d’incidence sur le MCD, sinon ça n’est pas un MCD. Que l’on prenne en compte — suite à événements — les modifications portant sur une entité-type (par exemple le changement de dénomination d’une entité juridique, son changement de NAF, de régime fiscal, de catégorie juridique, etc.) ceci reste simple à représenter dans le MCD quand on sait distinguer les données actives des données historisées et qu’on ne fourre pas tout dans le même sac. (En cela, la connaissance de la sixième forme normale n’est pas inutile).

le MCD ne doit pas engendrer une dénaturation des règles de gestion des données.

Je ne vois même pas comment on peut réaliser un MCD sans connaitre les règles de gestion à priori, sauf à modéliser des éléments triviaux dont la connaissance est supposée commune à tous. Donc le MCD ne peut être qu'une résultante de l'analyse exhaustive des règles métier. Sinon, il s'agit simplement d'un modéle anémique, inutile, et avec un risque d'adhérence élevé.

Merci de ne pas sortir une phrase de son contexte pour en dénaturer le sens. Comme je l’ai déjà dit, les règles de gestion des données préexistent, elles sont consignées dans le dossier de conception détaillé. Par exemple, quand il est écrit qu’une facture comporte au moins une ligne de facture, cela se traduit dans le MCD par une cardinalité minimum 1. Si l’on remplace cette cardinalité par 0, alors il y a bien dénaturation d’une règle de gestion des données. C’est le reproche que je faisais à hegros qui préconise, je cite, de « Prendre en compte uniquement la partie maximum pour les cardinalités ».

Quant à « l’anémie » des MCD et de leur « risque d’adhérence élevé », les participants et les visiteurs de ce forum doivent se perdre en conjectures, sauf peut-être s’ils s’appellent Sganarelle. Isn't it a little fuzzy?

Il est vrai que certains « top models » paraissent anémiés et que certains modèles de pneumatiques peuvent manquer d’adhérence au sol, mais à part cela...

Pour la modélisation des relations ternaires, disons simplement que la logique relationnelle n'est pas adaptée à des "dépendances logiques polymorphiques".
Le modèle objet l'est.

Ça présente bien, mais je ne vois pas ce que vous appelez une « dépendance logique polymorphique » (ça s’appelle peut-être encore autrement ?) Je ne vois pas non plus ce que les relations ternaires ont à voir avec ça. Quant à l’aspect polymorphique proprement dit, voulez-vous signifier qu’il s’agit du polymorphisme de type, au sens UML ou du Modèle Relationnel de Données ? Si oui, cela est abondamment traité dans la théorie relationnelle (cf. par exemple les chapitres 12 à 16 de l’ouvrage déjà cité, Databases, Types, and the Relational Model The Third Manifesto).

Autant j'adhére au DDD, autant là je me sens en plein anachronisme.

Conclusion : il vous reste donc plus qu’une seule chose à faire : vous retirer (sur la pointe des pieds).

« Tous les hommes sont mortels » ou « Quelques hommes sont mortels »

C'est fondamentalement identique pour nous. Cela veut dire que tout ou partie des hommes au sens logique peut un jour faire l'objet d'un événement "mort".
La seule différence va être au sens technique. C'est dans la façon dont sera représenté physiquement la capacité à mourrir que sera gérée la différence.

Là encore, vous sortez une phrase de son contexte, pour partir ailleurs. J’ai expliqué à hegros que transformer une cardinalité minimum 1 en 0 revenait à confondre la quantification universelle et la quantification existentielle, donc affirmer que les deux énoncés « Tous les hommes sont mortels », « Quelques hommes sont mortels » sont équivalents, ce qui est évidemment une erreur logique très grave. Si vous voulez en savoir plus, je vous conseille par exemple la lecture de l’ouvrage de Quine méthodes de logique, « Énoncés catégoriques » et là vous apprendrez que le 1er énoncé est du type A (universelle affirmative) et le 2e du type I (Particulière affirmative).

Un MCD "bien formé" peut tout à fait aboutir à un MPD parfait, alors que dans sa logique, il est anémique et inutile.

Qu’entendez-vous par « logique » d’un MCD ? Et une fois de plus, par « MCD anémique » ?

faire valider un cahier des charges n'a jamais signifié que les régles de gestion sont bonnes. C'est juste un transfert de responsabilités qui sert plus souvent d'excuse et de prétexte que de mesure de la qualité et de recensement.

Si les règles de gestion des données ne sont pas bonnes, c’est que le chef de projet n’a pas su accoucher la maîtrise d’œuvre. Et si le projet échoue, il en portera la responsabilité. Si les règles de gestion des données sont incomplètes et si le MCD est bien construit, on le fera évoluer en conséquence.
Ceci dit, quelle alternative proposez-vous à la validation des dossiers ? Que faire pour s’assurer que les règles de gestion des données soient réputées valides ? Merci de nous éclairer de vos lumières (qui pour le moment éteignent).

Par rapport au SI le MCD est beaucoup trop pauvre pour être une formalisation utile.

Si le MCD est parfois trop pauvre c’est parce qu’il ne prend pas en compte des concepts tels que l’héritage, la composition, l’agrégation, les contraintes d’inclusion, exclusion et autres : il faut donc le faire évoluer en ce sens (je vous renvoie à la FAQ Merise).

Cela dit, un MCD est malgré tout un excellent moyen de communication, et comme je l’écrivais dans un message précédent :

« Le MCD doit être crédible et clair, au point que la MOE et les équipes de développement décident d’afficher au mur les vues qui les concernent, plutôt que de s’en servir comme de ballons de basket, la poubelle jouant le rôle de panier. »

Maintenant, si le MCD ne suffit pas, on peut se référer à ses compagnons, le MCT (Modèle Conceptuel de Traitement) et le MCC (Modèle Conceptuel de Communication).

Le MCD pour moi est surtout un formalisme techniquement dépassé, beaucoup trop confiné au SQL.

Merci de démontrer en quoi le formalisme MCD est techniquement dépassé. Quant à sa relation avec SQL, sachez que les SGBD utilisant ce langage ont été mis sur le marché seulement quelques années après que l’on a commencé à produire des MCD. Merise date de la fin des années soixante-dix et, en France, les entreprises ont commencé à vraiment utiliser les SGBDR en production une dizaine d’années plus tard.

Une fois de plus vous mélangez complètement les niveaux, vous amalgamez abstraction (modélisation des données) et réalisation (SQL).

Je trouve simplement qu'en 2009, le DDD est beaucoup plus productif et efficient..

Grand bien vous fasse. J’espère que l’efficience de votre modélisation s’accompagne de la validité des résultats obtenus.

Quand je lis

Je suis désolé, mais lors des séances de validation fonctionnelle d’un MCD, doivent être présents le chef de projet et/ou le concepteur (qui connaissent tous deux parfaitement le dossier), ainsi que l’équipe fonctionnelle de la Maîtrise d’Oeuvre qui, je le répète, comprend en général très vite le dossier et ce qui a été modélisé (sauf si le MCD ressemble à une toile d’araignée ou à un chef-d’œuvre d’art contemporain). A défaut, en l’absence de séances de relecture en commun, je ne donne pas cher du projet.

C'est effrayant, ça veut dire que la conception est un organisme mono cellulaire qui travaille en mode non collaboratif, que de facto, toute réalisation complexe et lourde est à proscrire.

Qu’y a-t-il d’effrayant à ce que la Maîtrise d’ouvrage organise des réunions pour s’assurer que les équipes du projet et la Maîtrise d’œuvre sont bien toujours en phase ? Pour s’assurer qu’il n’y a pas eu de dérive ? Pour mettre à plat les points à revoir ? Certes, en début de projet, les équipes du projet (les informaticiens) et la Maîtrise d’œuvre sont pratiquement en permanence ensemble, mais ensuite les informaticiens modélisent à partir des résultats des travaux effectués en commun. C’est la moindre des choses que la MOA surveille ses troupes et l’avancement du projet (domaine par domaine).

Je rappelle une fois de plus qu’on urbanise un univers du discours en domaines, sous-domaines, etc. Un projet de refonte du SI d’une entreprise importante (je sais de quoi je parle) entraîne nécessairement l’urbanisation, donc la modélisation de plusieurs domaines, ce qui a notamment pour objet d’éviter une réalisation complexe et lourde qui se traduirait par la mort du projet. Et cela a pour effet que l’on constitue des équipes homogènes, de taille raisonnable, tant côté informatique que MOE.

La pire chance d'échec du projet c'est de n'avoir que 2 personnes qui connaissent parfaitement le sujet...Pas de révision, pas de droit à l'erreur, risques de sélection "dogmatiques".

C’est bien pour cela que l’on urbanise les projets d’une certaine ampleur. Pour chaque domaine, il y a un chef de projet et son équipe, même principe côté Maîtrise d’œuvre. Si un chef de projet tombe malade, son adjoint assure l’intérim, etc.
Rassurez-vous tout cela fait largement plus que seulement deux personnes connaissant le sujet...

En fait en rêgle de design aujourd'hui j'aurai plutôt tendance à

-Utiliser une clef technique (auto ou algo selon le sgbd) pour toutes les données sur lesquels je n'ai pas le décision de la norme
-Utiliser une clef codifiée pour toutes les données sur lesquels je défini leur norme

Si je dois identifier par exemple une plaque d'immatriculation, je considérerai que la norme de définition peut changer (d'ailleurs cas réel finalement) et j'utiliserai un identifiant automatique, et probablement une structure relationnelle pour identifier une immatriculation française avant 2008 ou après, us, belge,etc...

Je suppose que par « design » vous voulez dire modélisation. Si vous vous situez au niveau de la modélisation des données, que vient faire le SGBD ? Quant à codifier les clés (en fait les identifiants), je répète pour la nième fois ce qu’à écrit Yves Tabourier (De l’autre côté de MERISE page 81) :

« ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.
L’expérience montre d’ailleurs que l’usage des “identifiants significatifs” (ou “codes significatifs”) a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets... »

Tabourier a tiré les leçons du passé et nous demande quelque part d’avoir en mémoire ce que Goethe, Winston Churchill, George Santayana, Thomas Mann, et d'autres ont écrit :

Ceux qui ont oublié le passé sont condamnés à le revivre.

Je répète pour ma part qu’au niveau MCD, la plaque d’immatriculation (qui correspond à une propriété naturelle) ne peut faire l’objet que d’un identifiant alternatif (donc d’une clé alternative lors du passage au niveau base de données) et que l’identifiant d’une entité-type (donc la clé primaire d’une table au niveau base de données) ne décrit rien. L’utilisateur ne doit connaître que les propriétés naturelles, l’identifiant lui est caché. La plaque d’immatriculation ne figure qu’une fois dans l’univers du discours, donc dans la base de données qui en sera inférée. En ce qui le concerne, une fois traduit sous forme de clé primaire, l’identifiant sera propagé autant de fois qu’il y aura de contraintes référentielles dans lesquelles il est impliqué. C’est une question de bon sens que de ne lui associer aucune signification quelconque. Sa mission sera de garantir l’intégrité de la base de données (intégrité d’entité, intégrité référentielle), pas de décrire.

Ensuite, au niveau de la base de données, qu’un attribut participant à une clé primaire soit du type entier (séquentiel ou haché), timestamp (séquentiel ou haché), CHAR, VARCHAR, INTERVAL, etc., ceci est parfaitement orthogonal (indépendant) par rapport à la modélisation. Le choix définitif de ce type relève de la compétence du DBA et certainement pas du concepteur ou du développeur, qui sont plus concernés par l’aspect fonctionnel des choses.

Voyez encore http://www.developpez.net/forums/d79...d/#post4635515

Si par exemple, j'ai besoin pour x raison d'avoir un registre applicatif dans la base, j'utilise généralement une codification alphanumérique sur char(n), mais avec une validation du contenu (pas de blanc, caractères spéciaux)..
D'autant qu'il s'agit généralement de données cachées ou de paramètres applicatifs, l'impact en performance est complétement négligeable.

Parfois sur des besoins très particulier des séries temporelles longues avec des grosses volumétrie, j'utilise aussi des clefs binaires, mais davantage pour des motifs de tris, donc je peux être amené à le faire en char(n), mais c'est un cas très spécifique

J’espère que vous ne vous ne traitez pas ici des identifiants du niveau conceptuel, mais de propriétés disons naturelles (quitte à ce qu’elles fassent l’objet d’identifiants alternatifs).

En prenant un autre modèle que le relationnel avec des tables et colonnes si vous prenez comme représentation un graphe avec par exemple les mib il me semble que chaque noeud est identifié par un varchar...

Là encore, le choix du type des attributs est un problème de réalisation, pas de modélisation. Mais si, au niveau modélisation, vous avez malgré tout de très bonnes raisons de retenir le type VARCHAR plutôt que INTEGER, CHAR, ou ... NŒUD, vous aurez à convaincre le DBA (qui généralement n’est pas favorable à VARCHAR pour typer une clé).