Reprise du message précédent :
 

 
Une clé primaire est unique, et là je parlais d'aggréger plusieus champs, donc bien une PK.

NON
ils n'ont pas la même liberté de gestion des bugets par exemple

la CNIL demande à ne pas stocker de données d'identification sans qu'il y ait un besoin.  
Le numéro de sécu est une identification forte,mais il ne sert  à rien si l'agent n'est pas recruté au final. ( ce qui arrive : incapacité médicale par exemple ).
 
Donc on fait quoi ? on explique qu'on informatise pas le dossier tant que l'agent n'est pas recruté ? ou alors on stocke une données inutile et sensible ? Le moins pire est de purger les bases, mais c'est intenable au quotidien.

donc tu vas faire tes requetes de jointure avec ça ?  
ou alors tu ne te sers pas de ta primaire pour les jointures ? (auquel cas, c'est juste de la branlette de dBA si ta clé ne sort jamais de sa table )

 
Bah la fonction publique n'attire plus, donc pour recruter ils clonent des agents.
Comme les clones sont identiques, ils ont le même numéro de sécu. SécuFD.

Avec MySQL t'as une option de config de l'auto-incrément pour gérer ça :

En mettant des champs NOT NULL en UNIQUE ça revient à avoir une PK dessus.

Et quand ta clé naturelle évolue car le périmètre fonctionnel change ?
 
J'aime toujours ton côté radical skeye
 
Tu peux rendre plein de traitement génériques en partant du postulat que t'as une PK id en autoinc.

 
Il n'empêche qu'ils ont une certaine indépendance, je vois pas en quoi c'est gênant de les considérer dans la base comme des communes à part entière, pour le coup.
 

 
Je vois pas le rapport avec les numéros de sécu en double? Ca peut expliquer qu'on veuille utiliser autre chose comme clé, par contre, évidemment.

 
N'importe quelle valeur qui a un sens particulier est susceptible de changer, ne serait-ce que pour corriger une erreur de saisie...
 
Autre problème : ta clé sera lié à un attribut du monde réel sur lequel tu n'as aucun contrôle. Exemple : si tu identifies tes utilisateurs par un numéro de sécurité sociale, tu n'as aucune garantie qu'il n'y aura pas une réforme à un moment ou à un autre qui changera tout ça (et je parle pas d'un cas théorique, ça s'est produit en Suisse il y a quelques années)

4 agents en cours de recrutement
4 agents avec un numero de secu a null ( ou comme nous imposait le dernier soft rh 1111111111111 10 )
 
paf la PK ( et la contrainte d'unicité )

 
Exemple?
 

 
J'aime bien aussi.
 

 
Tu peux aussi pourrir d'autres fonctionnements automatiques parce-que ta clé n'aura plus le même nom lorsqu'elle sera utilisée en FK dans une autre table...

 
Ça a quand même un côté un peu bricolage... Le problème avec ce truc, c'est qu'une erreur de config peut faire que tu te retrouves avec des clés à double. Les GUID sont certainement la meilleure solution quand on doit gérer des données répliquées sur plusieurs bases.

C'est pas le cas

Il supporte pas les primary key composites, et les extensions tierces peuvent être codées avec les pieds, mais dans l'ORM même suffit de définir un champ avec primary_key=True et tu peux y mettre ce que tu veux. Ni le type ni le nom de la PK n'est hardcodé. D'où le champ virtuel pk dans les querysets.

Mon pb était avec des clefs primaires composites en fait, pas des uniques-mais-non-int-autoincrementée

Une base de données de bagnoles ou de plaques d'immatriculation en cours. Je sais pas si ça existe (dans les préfectures, peut-être) ou si le problème s'est posé, mais c'est une possibilité.

Ah oui là effectivement c'est pas géré du tout (même les unique composites sont un peu étranges, faut passer par Meta)

à-partir du moment où l'immatriculation peut changer faudrait être particulièrement crétin pour utiliser ça comme clé, effectivement.

Bon, je vais être obligé d'intervenir, pour le bien du débat.  
Ma question n'a donc à voir avec le débat. ;-)
 
Je suis bloqué sur un truc d’évènement en JavaScript :  
 
document.observe('click', creerSeanceVide); fonctionne bien sur tous les navigateurs (y compris IE9), sauf IE8. J'ai pas testé les versions plus anciennes.  
J'ai le même problème avec :
<input type="checkbox" onChange="afficherDebog(this);" value=true id="debog">
 
onChange n'est jamais déclanché sur IE8. Quelqu'un à une idée de la raison pour laquelle IE8 joue le rebel ?
(Petit détail, l'application est destinée à IE8, donc, oui, il faut que ça marche).
 
J'ai rien dis, ça fait pas ce que ça devrait, mais dans le cas du onChange, dès que je click ailleurs l’évènement est déclenché.

avant : une immatriculation = le lien entre un propriétaire (nom, prénom, adresse) et un véhicule .  
Après la reforme une imatriculation = plusieurs propriétaires
 
Si ta table qui fait le lien entre le propriétaire et le véhicule utilise la plaque d'immat en PK , tu es fucké. Si c'est juste un champ avec une contrainte d'unicité et que tu utilise des id tout con pour tes jointures, tu fais pété la contrainte et ça continue

Si tu utilises autres chose que la PK comme FK t'as sérieusement besoin de refaire un bilan de compétences, aussi.

Ben justement, si ta plaque d'immat est PK d'un truc qui contient de pret ou de loin une donnée de proprio (ce qui n'est pas déconnant au vu du sens qu'avaient les plaques d'immat) , tu as un énorme refactoring a faire lors de la reforme  
 
alors que si ta PK est un id sans aucun sens, ça ne change absolument rien

Je vois pas dans quel esprit dérangé une plaque d'immat. serait la PK de quoi que ce soit, puisque tu sais dès le départ ça peut changer...

(ou alors une table des immatriculations )

Faudrait pas que le champ perde le focus sous IE8 pour que l'évènement change soit lancé par hasard ?

un peu comme le numéro de sécu finalement. Le code insee aussi peu changer sous certaines conditions  
 
donc il n'y a pas de clé naturelle
 
CQFD

 
Deux exemples => une généralité.

C'est exactement ça.  
La solution, c'est quoi alors ?  
 
Pour le onClick, le problème, c'est que l'évenement ne se déclenche pas sur la bonne DIV (il prend la div parent au lieu de la div enfant). Pourquoi la propagation est différente entre IE8 et IE9 ?
 
Edit : pour le onChange, j'ai mis un onMouseUp, c'est pas parfait, mais c'est pour le débogage, ça à pas besoin d'être parfait.  
Par contre, pour mon problème de propagation, là c'est vraiment un problème.

Trouve moi un contre exemple
pour l'instant, les deux que tu as cité ( code INSEE, numéro de secu ) ne sont pas utilisables  

onkeyup pour les champ text , onclick pour les radio (mais attention a la navigation au clavier )

Relis, je n'ai lancé moi-même ni l'un ni l'autre.

Par exemple dans mon coeur de métier, les codes RNE des établissements d'enseignement sont adéquats. Si le code change c'est que l'établissement a changé. Tu ne veux pas changer le code, dans ce cas, tu veux en créer un nouveau, même si l'établissement a le même nom. C'est une clé naturelle.
Idem pour des mentions, par exemple. Avoir comme clé les abréviations ('P'=> 'Passable', 'AB'=>'Assez Bien', ...) est tout à fait acceptable, et permet même de déduire la valeur d'origine en regardant la table dans laquelle on trouve la colonne comme FK.

Relis, j'ai dis cité, pas lancé
 
C'est sûr que savoir si on mets un entier ou une lettre pour une table des mentions contenant 10 lignes, est fondamental
Tu as égayé ma journée pluvieuse, merci  
 

 
Ou qu'il y a eu une erreur à la saisie

 
Peu probable - codes fournis par le ministère, importés automatiquement.

 
Je n'ai jamais cité l'un de ceux-ci en tant que bonne pk, non?
 

J'ai plusieurs milliers d'établissements, si tu préfères.
Ou de diplômes. Ou d'unités d'enseignement. Ou...
 
Tu fais quoi, tu leurs donnes un numéro juste pour le fun? Parce-que le code naturel il leur faut, aux gestionnaires, hein...je les vois mal se rappeler que le n°955656 c'est le DUT génie civil, stuveux.
...et une fois que tu as un code unique et qui a du sens pour les gestionnaires, ton id autoinc c'est du bruit.

tu as des gestionnaires qui tapent directement en base  ?

parceque la PK , ou même la structure de la table  en génénral, c'est pas le genre de truc qui sortent du service info chez nous

 
 
Bon, en fait le problème de mon onClick venait de la fonction :  
event.element()
Cette fonction provient de prototype, et donc apparement ne marche pas avec IE8.

Non.
J'ai des gestionnaires qui créent/modifient des diplômes/UE/etc dans l'interface de l'appli. Et ils créent eux-même les codes naturels suivant une convention qui leur permet de les retrouver de tête.
Quand ils veulent retrouver quelque chose dans l'appli ils ne font pas une recherche pour retrouver le bon parmi les 12000 qui ressemblent, ils saisissent le code.

Ils savent pas que c'est la PK au sens technique. Ils savent que c'est le code unique de l'élément qu'ils manipulent.

ils se souviennent donc  ( ou ils peuvent retrouver )  de 12000 codes . J'adore le c'est unique parcequ'il essayent des codes jusqu'a en trouver un qui correspond aux conventions et qui n'est pas déjà pris.  
 
C'est vachement mieux qu'un id avec des mot clé par exemple

 
T'as aucune idée de la complexité du truc ou de la précision des conventions adoptées.
Et encore moins du temps qu'ils perdraient à faire des recherches par mots-clé à tout bout de champ.

Tu es le seul a bosser sur des choses compliqués, je t'assure.

Et tu as raison, j'en suis sûr.

Mais bon, comme j'aime bien avoir tort, je fais parti de ces gens qui font la chasse aux codes qui nécessite de connaitre par coeur un guide d'utilisation ou de connaitre la personne qui a créer le truc, pour mettre du langage naturel à la place. Jusqu'ici ça a été plutôt bien accueilli par les utilisateurs. Mais bon, j'imagine que je n'ai pas ton expérience et que je finirai par me ranger à ton avis.

 
Bizarrement, le fait que ça soit construit sur des conventions précises, c'est exactement le genre de choses qui me ferait éviter d'utiliser ça comme clé...

 
Il n'y a pas toujours de jolie solution pour tout. Quand t'as des tables de dizaines de milliers d'éléments aux noms qui peuvent être identiques (et ce n'est pas une erreur) et que les secrétaires doivent avoir un moyen rapide d'accéder si elles veulent pas passer leurs journées à faire des recherches, ce genre de codes est utile.

un peu comme une table qui contiendrai dans les 250K opérations de pompiers par exemple, dans laquelle on en cherche UNE.
J'ai traité ça avec des facettes sur certains mots clés qui sont normés  + recherche en texte libre ( qui porte aussi bien sur les mots clé normé, leurs synonymes, leurs abbrevations que sur les zone libres, genre la description )  
 
Le débutant peux découvrir les mots clés rapidement, le confirmer peut taper des abbréviations ( "SAP 2012 MER lessard" pour un  secours a personne en 2012 par le centre de mervans sur la commune de lessard en bresse )