Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1592 connectés 

  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  [MySQL] Identifiant et type de données

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[MySQL] Identifiant et type de données

n°1414354
Mario_
Vive le pingouiboulga !!
Posté le 27-07-2006 à 11:26:40  profilanswer
 

Bonjour,
 
Je débute un projet perso de pseudo-wiki en j2ee sous Mysql. Jusque là, je référenciais les articles par un identifiant entier unique.
Par exemple, un article qui aurait pour titre "Eléments de réponse" aurait été codé sous la forme :

id    title                 content
1     Eléments de réponse   blabla


 
Pour pouvoir éviter les doublons de titre, je comptais mettre un "intern_title" qui donnerait par exemple elements_de_reponse pour le titre de cet article. Ainsi, quelqu'un qui créerait un article avec pour titre "eléments de REPONSE" se verrait refuser l'ajout de son article après un simple traitement (il serait considéré comme équivalent à l'"intern_title" de l'article 1).
 
Donc ça donnerait :

id    intern_title         title                   content
1     elements_de_reponse   Eléments de réponse    blabla


 
Le truc c'est que maintenant, au moins sur le plan théorique, intern_title pourrait jouer le rôle de clé unique pour l'article. Mais est-ce une bonne idée sous Mysql ?
 
Je n'ai pas besoin de l'auto-incrémentation (puisque je génèrerais moi-même cette clé) mais puis-je utiliser une clé VARCHAR de longueur indéfinie (ou du moins suffisamment longue) pour permettre d'utiliser l'intern_title en temps que clé primaire de la table ? N'y aura-t-il pas des risques de perte de vitesse de l'appli à l'accès en particulier ?
 
Merci d'avance :jap:

Message cité 1 fois
Message édité par Mario_ le 27-07-2006 à 11:27:26

---------------
Soyons ouverts d'esprit, mais pas au point de laisser notre cerveau s'enfuir.
mood
Publicité
Posté le 27-07-2006 à 11:26:40  profilanswer
 

n°1414363
couak
Posté le 27-07-2006 à 11:37:03  profilanswer
 

oui

n°1414378
Mario_
Vive le pingouiboulga !!
Posté le 27-07-2006 à 11:48:28  profilanswer
 

Merci :jap:


---------------
Soyons ouverts d'esprit, mais pas au point de laisser notre cerveau s'enfuir.
n°1414380
Sve@r
Posté le 27-07-2006 à 11:51:11  profilanswer
 

Mario_ a écrit :

id    intern_title         title                   content
1     elements_de_reponse   Eléments de réponse    blabla


 
Le truc c'est que maintenant, au moins sur le plan théorique, intern_title pourrait jouer le rôle de clé unique pour l'article. Mais est-ce une bonne idée sous Mysql ?
 
Je n'ai pas besoin de l'auto-incrémentation (puisque je génèrerais moi-même cette clé) mais puis-je utiliser une clé VARCHAR de longueur indéfinie (ou du moins suffisamment longue) pour permettre d'utiliser l'intern_title en temps que clé primaire de la table ? N'y aura-t-il pas des risques de perte de vitesse de l'appli à l'accès en particulier ?
 
Merci d'avance :jap:


 
Le vrai pb c'est que si ta table est liée à une autre, le lien se fait par recopie de ta clef primaire comme clef étrangère dans l'autre table. Si ta clef est une chaîne de caractères, là tu auras une réelle perte de perfs.
 
Par ailleurs, une règle de base veut qu'une clef primaire soit indépendante des autres champs. Or là, ta clef potentielle "intern_title" est issue d'un algo sur le champ "title". Que se passera-t-il le jour où le contenu est modifié ???
 
A mon avis, vaut mieux garder ta clef primaire telle qu'elle et n'utiliser "intern-title" que pour gérer le pb des doublons sur "title"...

n°1414389
Mario_
Vive le pingouiboulga !!
Posté le 27-07-2006 à 11:55:45  profilanswer
 

Sve@r a écrit :

Le vrai pb c'est que si ta table est liée à une autre, le lien se fait par recopie de ta clef primaire comme clef étrangère dans l'autre table. Si ta clef est une chaîne de caractères, là tu auras une réelle perte de perfs.
 
Par ailleurs, une règle de base veut qu'une clef primaire soit indépendante des autres champs. Or là, ta clef potentielle "intern_title" est issue d'un algo sur le champ "title". Que se passera-t-il le jour où le contenu est modifié ???
 
A mon avis, vaut mieux garder ta clef primaire telle qu'elle et n'utiliser "intern-title" que pour gérer le pb des doublons sur "title"...


J'avais pas pensé au problème des liens et de la modif du titre, c'est très exact [:figti]
Bon ben au final, je vais peut-être en rester aux deux champs title et intern_title et à l'identifiant indépendant. En mettant peut-être un index sur intern_title.
 
Merci :)


Message édité par Mario_ le 27-07-2006 à 11:56:11

---------------
Soyons ouverts d'esprit, mais pas au point de laisser notre cerveau s'enfuir.
n°1414390
chani_t
From Dune
Posté le 27-07-2006 à 11:56:04  profilanswer
 

Sve@r a écrit :

Le vrai pb c'est que si ta table est liée à une autre, le lien se fait par recopie de ta clef primaire comme clef étrangère dans l'autre table. Si ta clef est une chaîne de caractères, là tu auras une réelle perte de perfs.
 
Par ailleurs, une règle de base veut qu'une clef primaire soit indépendante des autres champs. Or là, ta clef potentielle "intern_title" est issue d'un algo sur le champ "title". Que se passera-t-il le jour où le contenu est modifié ???
 
A mon avis, vaut mieux garder ta clef primaire telle qu'elle et n'utiliser "intern-title" que pour gérer le pb des doublons sur "title"...


 
+1...
 
une bonne clef primaire numérique, (bigint si t'as vraiment beaucoup de lignes prévues), et le lien entre deux tables se fais facilement et rapidement...( et pas besoin de gérer des doublons potentiel)

n°1414393
Mario_
Vive le pingouiboulga !!
Posté le 27-07-2006 à 11:57:50  profilanswer
 

chani_t a écrit :

+1...
 
une bonne clef primaire numérique, (bigint si t'as vraiment beaucoup de lignes prévues), et le lien entre deux tables se fais facilement et rapidement...( et pas besoin de gérer des doublons potentiel)


Peu probable, dans mon idée ce n'est pas voué à être un wiki "encyclopédique" donc un int de la "bonne taille (j'ai mis une taille 10 jusque là mais c'est plus par défaut qu'autre chose) devrait amplement me convenir.
 
Merci de vos réponses :jap:


---------------
Soyons ouverts d'esprit, mais pas au point de laisser notre cerveau s'enfuir.

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  [MySQL] Identifiant et type de données

 

Sujets relatifs
Affichage étrange de données hexa contenues dans un buffer [Résolu]Fonction du type ereg
Problèmes d'accent sous MySql[RESOLU]Lire quelques valeurs sur une base Mysql d'un forum ipb
export base Mysql vers fichier excel[C++ / résolu] Vérifier le type donné à un template... typeid?
MySQL 5 -- Syntaxe SQL[Access] VBA récuperer données requête
[Resolu] Type de control (VBA)Probleme incompatibilite données acces/VBA [résolu]
Plus de sujets relatifs à : [MySQL] Identifiant et type de données


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR