Eh bien je ne peux pas faire de HModifie! Y'a t'il une solution? Posté le 14 décembre 2007 - 15:02 Bonjour, vous devez avoir ID1, ID2 cle avec doublon et une cle composé (ajouter la dans votre analyse) ID1+ID2 cle unique bon dev @+ Gabriel H. a écrit: Bonjour, Je suis confronté à un problème. Eh bien je ne peux pas faire de HModifie! Y'a t'il une solution? Posté le 14 décembre 2007 - 15:05 Bonjour, Déclare tes deux clés en clés avec doublon, et fait une clé composée clé unique. Hubert Posté le 14 décembre 2007 - 15:21 Bonjour, Si je ne m'abuse, tu peux créer une clé composée unique dans HF, qui te sert alors de clé primaire. >Est ce que cela a un sens de vouloir 2 clés uniques dans une table? Parfois oui, j'ai le cas dans ma base, pour ma table article: la référence qui est la clé unique de la table (nom modifiable, car utilisé pour les clés étrangères), et un autre champ (nom d'appel) qui est lui aussi unique (mais modifiable). C'est un "héritage" de notre ERP avec lequel ma base est interfacée.
Pour savoir ce qu'est une clé composite, nous devons savoir ce qu'est une clé primaire, une clé primaire est une colonne qui a une valeur unique et non nulle dans une table SQL. Maintenant, une clé composite est également une clé primaire, mais la différence est qu'elle est constituée par la combinaison de plusieurs colonnes pour identifier la ligne particulière dans la table. Clé composée: Une clé composite est constituée de la combinaison de deux colonnes ou plus dans une table qui peut être utilisée pour identifier de manière unique chaque ligne de la table lorsque les colonnes sont combinées, l'unicité d'une ligne est garantie, mais lorsqu'elle est prise individuellement, elle ne garantit pas l'unicité, ou il peut également être compris comme une clé primaire constituée par la combinaison de deux ou plusieurs attributs pour identifier de manière unique chaque ligne d'une table. Noter: Une clé composite peut également être constituée par la combinaison de plusieurs clés candidates.
/course/' (errno: 150) La table sponsoriser dépend de la table compétition (clé primaire: code_comp) et de la table sponsor (clé primaire: num_spons). Un sponsor peut sponsoriser plusieurs compétitions. Une compétition peut être sponsorisée par plusieurs sponsors. Merci! 25/07/2003, 14h06 #2 Pourquoi veux-tu avoir: primary key & #40;ref_comp, ref_spons) Laisse cela en index avec doublons. Rédacteur PHP / Delphi ADO / Novell / Inutile de m'envoyer vos questions par MP, je ne réponds que par le forum. 25/07/2003, 16h26 #3 C'est paskeu elle a fé son analyse avec Merise et qu'elle s'est retrouvée avec une assotiation NN Pour ton problème, ptet qu'il fo installer un truc supplémentaire pour pouvoir utiliser les tables InnoDB.. chais po 25/07/2003, 16h50 #4 25/07/2003, 17h06 #5 Ah, euh, essaye sans les "foreign key (.. )" 8) 28/07/2003, 14h38 #6 Je pense que je devrais mettre la clé en AutoIncrement. Les foreign key c'est obligatoire car c'est des tables InnoDB. Merci!! + Répondre à la discussion Cette discussion est résolue.
Astuce: Voici deux requêtes vous permettant de trouver le prochain id disponible (puisqu'on ne peut plus utiliser d' AUTO_INCREMENT sur notre clé primaire): SELECT id AS last FROM documents ORDER BY id DESC LIMIT 1 Celle ci vous permet de récupérer le dernier id attribué. SELECT MAX ( id)+ 1 AS next FROM documents Et cette dernière vous donne directement l'id à utiliser (mais a l'inconvénient de ne pas utiliser l'index).
Presque tout le développement actif dans MySQL et MariaDB se fait dans le moteur InnoDB. Il possède également de nombreuses fonctionnalités qui manquent à MyISAM, comme le support et les transactions FOREIGN KEY.
Le 10/11/2004 à 16:44 # 13802781 Stéphane a exposé le 10/11/2004: Jean Cougnaud wrote: Les fichiers Hyperfile contiennent des clés composées. Est-ce que cela existe aussi en MySql? Oui cela devient un index sur ta table. Sans être un spécialiste je crois effectivement que cela existe. Mais je te conseillerais plutôt de revoir l'analyse pour utiliser un autre système plus performant: id unique auto incrément en index principal puis plusieurs champs d'index secondaires à définir éventuellement avec un outil d'analyse de charge (ça existe sous SQLServer). Mon avis = Tout Pareil!!! Car les clés composés sont une mauvaise solution en sgbd. Je pense qu'il vaut mieux que tu rajoutes une clé "technique" de type auto incrément pour tes clés primaires et utiliser les autres infos comme des index. -- Eric Roumégou (cliquez sur le lien ci-dessus pour me contacter en privé)