Reprise du message précédent :

Toi, t'es du genre à utiliser un N° Siret pour identifier une entreprise !
 
"Pfiou, suis content, j'ai saisi toutes mes entreprises !"
"Ha, mince, je me suis planté dans la moitié de mes N° SIRET ! Comment je peux faire ?"
 
"Ha ben attendez, on va tout supprimer pour tout recréer !"
 
Que ce soit fait de façon automatique ou non, s'il faut en venir là, c'est qu'il y a eu un problème de conception.

C'est même pas ça vu que tu peux l'écrire en PHP aussi, faut juste penser à mettre le tout dans une transaction

Si tu remplis tes BDDs à la main, j'pense que tu devrais changer de boulot

Il y a surtout eu un problème d'embauche, faut virer les RH

'fin bref perso je me tape une base de données avec des clés pas naturelles du tout, et ça me casse fortement les couilles de devoir systématiquement faire une jointure sur une table d'une centaine de milliers d'enregistrements (oué mais ya un index, lol ) parce-que le champ sur lequel je veux chercher n'est pas utilisé comme clé alors que c'en est une naturellement...

Nan, faut pas exagéré. Y'a 20 tables, c'est bon, j'ai un peu analysé le modèle. Il est mal foutu, c'est tout !
Les users sont identifiés par leur Login, et les entreprises par le N° Siret, lui-même stocké, non pas sous forme de chaîne de caractère, mais dans un big-int
 
Faut pas abuser quand même ²

C'est pas emmerdant d'avoir plusieurs fois le même nom d'utilisateur selon toi? ( Honest question inside )
Ça me parait logique de demander à l'utilisateur de choisir un autre login.

Bah le mec qui a créé la DB est bête, il aurait du créer un datatype custom pour les SIRET, qui autovérifie sa validité

Mon collègue a livrer l'appli que j'ai rapidement décris. Je me tape donc la maintenance. C'est le client qui m'a demandé si on pouvait changer les N° Siret parce qu'il y a eu des erreurs de saisi.
 
C'est donc à moi de gérer tout ce merdier maintenant

Oui, il aurait dû.
 
Le problème, c'est qu'il a été parachuté sur ce projet, tout seul, alors qu'il sortait tout juste de l'école, sans qui que ce soit pour l'aider, le conseiller, le guider, ...

 
Bah tu implémentes la copie/modif des liens/suppression, ça a franchement rien de sorcier sur une base avec 20 tables.

 
...et pour toi le problème c'est donc l'utilisation de clés naturelles?

Oui ! Pis, c'est pas comme si j'avais plein d'autres trucs à faire pour avant-hier !
 
Toute façon, va bien falloir que je l'implémente cette feature. Mais c'était juste pour illustrer le fait qu'une données "naturelle" utilisée en tant que PK, même si elle semble, au premier abord, absolument unique et fiable dans le temps, peut ne pas l'être.

Si c'est une question de perfs, pourquoi tu dénormalises pas ?

un changement de SIReT fait parti de la vie d'une entreprise , meme sans erreur de saisie
 
un login non ( on change de nom , de prénom a la limite, mais le login est déjà, par définition quelque chose d'artificiel )

Même question que Skeye, pour toi au final le problème est dans l'utilisation des clés naturelles?

Si, elle l'est. Si tes clients sont des boulets ça ne change absolument pas le fait qu'un numéro SIRET est unique et fiable.
Après s'ils font n'importe-quoi et demandent des features qui n'ont pas lieu d'être, libre à vous de facturer en supplément...

Bin euh si ? Comprends pas la question, en fait
Ce que je veux dire c'est : si le gars peut choisir son login, y a de bonnes chances pour qu'un jour un type en choisisse un qui est déjà pris. Dans ce cas, ma question était : comment vous gérez ? (suggestions de logins dispos "qui ressemblent" genre GMail, vous le laissez pourrir avec juste le message d'erreur, etc...) Et les questions bonus : faut valider que le login remplisse certaines conditions (caractères, tailel max, etc...) et c'est casse-coupieds, surtout quand c'est mal fait
Dans la plupart des grosses boîtes avec plein de gens dedans, ils choisissent une nomenclature de login et pan, c'est généré auto. Du point de vue sysadmin, y a aucun gain à laisser le user choisir son login (enfin en tout cas j'en vois pas là comme ça), d'où mes interrogations Après, sur un forome ou une PME, st'ôt chose.

Oui mais le SIREN non, et la seconde partie du SIRET marche à la localisation, donc ça se gère assez facilement si tu réfléchis un peu.

Si tu veux juste faire référence à des boites tu stockes le SIREN, si t'as besoin de faire référence à des sites t'ajoutes le NIC, et si un site bouge, ben me semble logique que le NIC change.

Franchement le SIRET est loin d'être con comme truc (pour une fois…), je vois vraiment aucun intérêt à utiliser une clé artificielle juste pour le remplacer…

 
Parce-que je ne fais qu'utiliser cette base, c'est pas la mienne.
Pas une question de perfs (avec des index bien foutus tu as pas une grosse différence), une question de simplicité des requêtes et de logique.
 
Et dénormaliser les 450 tables ça me prendrait un poil plus longtemps que d'ajouter une jointure à mes requêtes.

Non. Là, y'a clairement d'autres problèmes.
 
Au sujet des clés naturelles, ce que je voulais illustrer ici, c'était genre une erreur de saisie du N° Siret.
Si c'est la PK, la modification de cette données n'est pas triviale.

C'est quand même très contextuel tout ça... Tu bouges ton site dans un autre pays et c'est plus valable.

mauvaise foi spotted

Euh non, si tu restes en France mais que tu acceptes les entreprises étrangères c'est plus valable non plus, si tu veux.

c'est pas comme si c'était le premier post comme ça

m'enfin ça tu le sais dès la conception, et tu sais très bien que ça exclut tout identifiant national d'entrée de jeu...

une idée de pourquoi un header('Location: mapage.php') pourrait ne pas fonctionner, sans faire aucune erreur?

sauf que si tu choisi une clé en bigint tu vas etre limité a 2^chéplukoi enregistrement, ça peut etre problématique aussi ,non ?  
 

Un N° Siret n'est pas unique et fiable. Les données naturelles unique et fiable, ça n'existe pas. Erreur de saisie, modification des normes en vigueur, ...

Pas forcément, une appli ça évolue, et c'est fait pour évoluer

Ce que je veux dire c'est que l'inconvénient d'une clé naturelle même bien pensée, c'est que dans 80% des cas elle unique contextuellement, et pas intrinsèquement. Elle est attachée à un environnement, et si l'environnement change, c'est toute la base du design qui change.

Après c'est toujours pareil, faut voir ce que ça apporte et ce que ça enlève comme avantages, mais ya pas que des avantages aux clés naturelles (en ce qui me concerne, je vois surtout les inconvénients pour l'instant )

 
l'affichage des erreurs est désactivé dans le php.ini.
 

 
Et ton cul il est sujet à erreurs de saisie?

Ah mais bien sûr, une appli ça évolue mais sans jamais aucune évolution sur le schéma de la base de données, suis-je bête.

nop, c'est bien la première chose à laquelle j'ai pensé , j'ai fait un error_reporting(E_ALL) dans l'doute mais non il en veut pas de mon header, comme si la ligne n'existait pas

et si t'ajoutes un die() derrière il se passe quoi?

ben page blanche

en fait c'est relativement étrange, ce header je le fait après validation d'un formulaire:
donc si je met un die après le header ça donne ça :
- je valide mon formulaire une première fois --> page blanche
- je fait F5, voulez-vous renvoyer blablabla -> oui. et là magique ça redirige comme il faut (et il resubmit mon form une deuxième fois au passage)

quel navigateur ?  

Le moins possible sur les trucs les plus basiques, si possible, ouais.
 

c'est display_errors pour afficher les erreurs

il fait quoi ton script après le header() en temps normal?

FF 3.5
 
et si je redirige vers une autre page (index.php en l'occurence) ça marche et sur mon autre page je vois vraiment pas ce qui pourrait bloquer

Un SIRET a 14 chiffres, suffit de 47 bits pour pouvoir tous les stocker

 
Et un pingouino pour l'ensemble de ton oeuvre:    

Si le contexte change, dans la majorité des cas le business change avec et il me semble logique que la db ait à évoluer avec le business. Perso ça me choque pas.
 
Et dans tous les cas, t'as des trucs qui devront changer dans ta db si l'environnement change En concevant bien ta DB et en la lockant au maximum, tu t'assures que le changement de l'environnement sera vu par la db et ne donnera pas des résultats corrompus (genre parce que tes routines d'insertion trop permissives auront récupéré les nouvelles données et les auront balancées de force dans les anciens champs).

Non mais c'est quoi ta définition de "header('Location: mapage.php') ne marche pas", alors? Il se passe quoi exactement?