Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
clés primaires dans hyperfilesql
Bonjour,
Voici ma question, en m'excusant d'avance si un sujet l'a déjà traité (si oui, donnez moi le lien, parce-que la recherche, elle, n'a pas suffit) :
Windev fait-il la différence dans hyperfilesql entre une clé primaire d'une part et une clé unique avec une contrainte non null d'autre part ?
Autrement dit, fait-il la différence entre une clé primaire et une clé candidate ?
Et donc, si oui, comment ?
Merci d'avance pour vos réponses.
Bonne journée.
Une clé primaire est forcément une clé unique non null, donc je vois pas trop la différence.
slt william,
En effet windev fait la différence entre une clé canditate et une clé primaire.Je te rappelle que une clé canditate est n'importe quel attribut pouvant assurer l'unicité de chaque enregistrement.
Comment il le fait? si vous déclarer votre clé primaire, il la prendra en compte pour vous parcours sur les traitement du fichiers , le reste des clé candidates auront le même comportement que les autres clé landa.
cordialement
D'abord, merci beaucoup pour vos réponses JOr_x et Paul Nero.
Je repars sur le pb.
Après ce que vous m'avez dit Paul, tout le souci est là justement :
Comment déclarer une clé "clé primaire" dans WD ?
Parce-que par exemple, j'ai une table(fichier dans WD) avec un attribut (rubrique dans WD) nommé ID qui est clé primaire donc non null et unique et j'ai, dans cette même table, un autre attribut qui est LIBELLE qui est aussi non null et unique.
Et bien systématiquement, après avoir défini les contraintes de non nullité et d'unicité sur les 2 attributs, il me dit que ID est clé primaire, ok, mais que LIBELLE est clé primaire aussi (dans l'interface de l'analyse, il me le souligne). Je me retrouve donc avec 2 clés primaires distinctes.
Or, avoir deux clés primaires (que je distingue avec une clé primaire composées de 2 attributs) n'est pas correct dans une table et surtout, tout simplement, ce n'est pas ce que je veux. Je veux que seul l'attribut ID soit clé primaire. Et bien c'est impossible à définir.
Je ne suis pas un grand pro de WD, loin de là, donc je passe surement à côté de quelque-chose mais je bloque quand même.
Si le mot
Bonjour,
je n'ai jamais eu cela.Mais si ce que vous dites est vrai c'est qu'il y a une certaine défaillance de l'outil.
Je vous conseille de déclarer une seule rubrique numérique clé primaire.Si votre projet ne le permet pas,vous pouvez déclarer des clés composés, mais cela doit respecter les règles de conception (2e et 3e forme normale ).Mais en aucun cas ne déclarez deux clés primaires distinctes même si windev le permet, cela peut vous embrouiller lors des traitements avec les fonctions usuelles (Hlit,HlitRecherche,...).
cordialement
Je serais toi, je mettrais que ID en contrainte unique non null pour le libelle je ne le mettrais pas unique, mais je le gérerais dans l'application pour pas qu'il n'y ait de doublons.
De toute manière, dès lors que je pose les contraintes de non nullité et d'unicité sur mon attribut, WD se charge de le définir comme étant clé primaire, même si ma table en dispose déjà d'une, que je le veuille ou non.
La réponse facile c'est que le problème viens de HyperFileSQL.
Est-ce plausible ?
Cela peut être plausible, même dans dans gros sgbdr comme oracle on trouve encore des anomalies.
ecrivez à PCSOFT pour leur demander.
bon dev
JOr_x :
Merci, je vais faire comme ça, je crois que c'est la meilleure solution pour contourner ce problème.
Même si le souci est ammener à se répéter étant donné le nombre de tables dans la base de données. Ca va se régler au cas par cas, dommage.
Merci encore à vous pour les réponses.
Bonne journée
je vous le disais déja dans mon message 5!!!Je vous conseille de déclarer une seule rubrique numérique clé primaire
bon dev
Au temps pr moi, je ne l'avais pas compris de cette manière là.
C'est le caractère "numérique" de la clé primaire que vous suggériez qui m'a perturbé.
Merci.
A la lecture de ce message, je me pose une question : Pourquoi n'avoir qu'une clé primaire dans la table ?
Personnellement dans toutes nos tables, nous avons toujours 2 clés primaire. La première un Id auto incrémenté de Windev (qui ne nous n'utilisons jamais) et la "vrai" clé primaire (par exemple le code produit dans notre table produit).
Cela ne nous à jamais posé de problème.
Quand PaulNero dit "Mais en aucun cas ne déclarez deux clés primaires distinctes" est-ce simplement lié aux règles de conception (2e et 3e forme normale ) citées ? Ce serait donc "juste" un problème de philosophie dans la conception.
slt ErwanA,
C'est peut être lié à une philosophie de conception.Je suis certainement allé trop vite pour les 2e et 3e formes normales en fait, je voulais faire état de la stabilité lors des traitements.Et l'iD automatique est souvent proposé par windev quand vous n'avez pas défini une clé primaire.
Mais, william parle du cas ou vous déclarez deux rubriques comme clé primaire allant de la conception même jusqu'à dans l'analyse windev.Vous voyez que cela pourrait être gênant.
bon dev
Merci je comprend mieux.
J'ai profité de cette discussion pour apprendre la notion de clé candidate. Ca pourra mettre utile.
William, si tu définis 2 attributs comme UNIQUE et NON-NULLABLE, ce sont par définition 2 clés primaires.Envoyé par William-Brenouille
Donc il n'y a pas de pb.
Cdlt, Arnaud.
Ce sont deux clé candidates.
Clé primaire pourrait aussi se dire "Première clé", et dans les clés, il n'y a pas d'ex aequo à la première place. Les autres sont bien des clés candidates.
Pour être complet, si l'idée vous venait de prendre une clé pour qu'elle devienne clé étrangère dans une table, et l'autre clé pour une autre table, sachez que ça marchera, mais je pense que c'est totalement dénormalisé. Ça rend donc la maintenance un peu plus délicate pour ce point.
Nous en avons personnellement une dans notre analyse. Le besoin de faire un report automatisé et d'une chaine de caractères d'une table vers une autre nous a poussé dans cette direction. Pour le reste des fichiers, nous avons des ID Auto.
Presque : Pour les puristes (donc exit les habitués des n° de séquence automatique par défaut) à l'issue du MLD nous avons des clés primaires, des clés candidates (ou alternatives) et des clés étrangères. Héritge de Merise.
Une clé primaire est un index unique non null.
Une clé candidate est transposée comme un index unique (qui peut donc accepter la valeur null au contraire d'une clé primaire).
Rien n'empeche par contre d'avoir une clé candidate non null aussi.
L'exemple type pour expliquer la clé candidate c'est le n° de sécu français d'une personne, il est unique mais néanmoins on ne s'en sert pas comme clé primaire.
Comment réagit WinDev si vous lui donnez un index unique nullable ?
Le problème ne se pose pas par défaut, car Hyperfile ne gère normalement pas les null. Je sais qu'on peut le faire, mais je crois que peu de gens l'activent (nous non en tous cas).
Peut être.
Mais concrètement ça ne change rien, car les deux clés étant déclarés unique et non-nullable, elles subissent les mêmes contraintes.
Et ça arrive régulièrement d'avoir 2 clés primaires dans nos applications.
- une clé primaire "technique" (un id auto), qui pour des raisons de performance et de pérennité est la clé étrangère dans les autres tables
- une clé primaire "métier" qui est également unique et non-nullable (ex : référence de sinistre, réf de produit, matricule salarié...).
Souvent la clé primaire "métier" n'est pas retenue comme seule clé primaire car on n'est pas sûr de sa stabilité sur le long terme (est ce que le système de numérotation des matricules ne va pas changer, etc...,) et donc on préfère éviter de la propager dans d'autres tables.
Il est donc possible que sur le long terme, il faille lever les contraintes d'unicité et/ou de non-nullité sur cette clé, par exemple lors d'un changement de référentiel.
Pour autant, il est souvent utile de garder cette clé métier qui de plus, parfois, sert également de critère de recherche pour l'utilisateur.
Il arrive également que la clé primaire "naturelle" (métier) soit une clé composée de différentes colonnes, et donc assez longue en taille (ex : 50 caractères ou plus). Là encore, on préfère éviter de la propager comme clé étrangère dans d'autres tables.
Là encore, pour autant, on gardera cette clé composite unique et non-nullable, car elle permet de contrôler l'intégrité des données saisies.
Bon je suis d'accord qu'en termes de normalisation pure, ça ne tient pas forcément la route, mais concrètement il n'y a pas d'inconvénients à avoir 2 clés primaires et mieux vaut en avoir trop que pas assez
La difficulté est que si on utilise une base externe comme postgresql par exemble, celle-ci ne va pas accepter 2 clés primaires, et on sera obligé de déclarer 2 colonnes "simples" puis de poser une contrainte de PK multi-colonnes sur les 2 colonnes en question.
Cdlt, Arnaud.
Intéressante discussion...
Selon mon expérience, il devrait y avoir qu'une seule clef primaire par table. Ou deux, dans les cas de Many To Many. Par défaut, il est simple et efficace d'y aller avec la clef primaire de HF : celle qui se génère avec l'incrément.
Par contre, l'incrément possède un problème en soi. Lors de corruptions de BD (ça finit toujours par arriver), il faut quelques fois charger les tables avec les informations. Dans ces cas la, la clef primaire cause un gros problème... car l'incrément s'exécute de nouveau sur chargement.
Il m'est arrivé de devoir recharger des tables ORACLE. Avant chargement, je transforme ma clef primaire incrémentable par un champs numérique simple. Après chargement, je remets la notion d'incrément.
Dans ORACLE 7 et 8, par défaut, l'incrément se remet en place en considérant les valeurs uniques chargées.
Qu'en est-il avec HF ? Autrement, une approche intéressante serait d'y aller avec une clef significative simple : DATE + HEURE + Hasard (9999). Cette clef offre l'avantage d'être informative... Sans passer par une gestion du timestamp "Date de création" et "heure de création".
Il existe certaines normes au sujet de l'utilisation des clefs. J'avais quelques informations prises à l'université. Et dénicher quelques recommandations trouvées au MIT... je vais fouiller dans mes TP. Ou Seattle ? Plus sur...
Jean-François
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager