Reprise du message précédent :

Ce smiley a plusieurs interprétations: ou  

du coup ça aide pas trop

dans le sens que j'ai une large préférence pour symfony (du moins ce que j'en connais)
disons que zend m'a l'air beaucoup moins assisté, ça a ses avantages et ses inconvénients
entre autre je pense qu'avec Zend c'est beaucoup plus simple de piocher quelques classes dans le framework sans devoir tout utiliser
 
mais d'un autre côté, apprendre zend tout seul c'est super chiant je trouve

Uh non, la seule interprétation c'est "I came"

J'ai pas dit que c'était compliqué, j'ai dit que c'était idiot.

bin il a quand meme une tete de si on ne connait pas la source

la dernière fois que j'ai regardé il y avait un quickstart qui donnait toutes les infos pas évidentes, et une doc complète...c'est plus le cas?

je pense que c'est mieux qu'avant de toute façon, mais la dernière fois que j'ai voulu l'utiliser, j'ai tenté de prendre juste quelques classes pour l'utiliser sur un projet déjà existant, et j'ai galéré ma race pour piger la plupart des trucs
 
après l'erreur que j'ai fait je pense, c'est de vouloir utiliser certains composant sans vraiment connaitre l'ensemble du FW correctement (puis ça faisait un baille que je l'avais pas utilisé)
 
sinon ouai je pense que y'a pas mal de tuto sympas, et je crois qu'en plus ils ont rajouté un outil en ligne de commande à la symfony sur les dernières versions.
Mais bon je sais pas symfony me donne une meilleur impression dans l'ensemble, et m'avait l'air plus simple à prendre en main.

oui, si j'ai bien suivi c'était plutôt une collection de classes utilisables facilement en standalone à l'origine, mais ça évolue plutôt vers le tout intégré fortement lié...un peu dommage amha.

Tu as un cron qui te fais un UPDATE age=age+1 tous les ans ?    

Il faut aussi qu'il soit fixe (mariage/divorce/etc).
 
Disons que théoriquement il faudrait utiliser l'Id.
Mais pratiquement, si ça se justifie par un gain visible, ça peut se défendre...

tiens, les table myisam gèrent pas les clé étrangères, on en apprend tous les jours

c'est quoi les avantages/inconvénients entre myisam/innodb?
et est ce que ça pose un soucis d'utiliser les deux types sur une même base?

Toutes les raisons théoriques disent de pas utiliser d'id autogénéré. Dans 99% des cas, si t'as des ids autogénéré, t'es pas dans une forme normale.

MyISAM => va vite si t'as surtout des lectures
InnoDB => évite de corrompre ses données, va vite en écriture, n'est pas complètement merdique.

 
C'est simple, myisam c'est de la grosse merde, et innodb un peu moins.

ok
Ma bdd est en full myisam \o/

Et tu utilises quoi ?
Dans une table MEMBRES, je ne vois pas ce qui pourrait être à la fois unique et fixe. A part un Id autogénéré...

le login?
Membres de quoi, d'abord?

Mon pénis est unique, et trop massif pour être déplacé.

Ba ça dépend comment tu génères ton login Si tu mets des trucs genre "NOM_DU_GARS", tu vas te retrouver rapidement emmerdé avec les "DUPONT_1", "MARTIN_3", etc... Ou alors t'as des logins auto-générés imbitables style "rtj45h" auxquels l'ID auto-increment d'a rien à envier

Le login est choisi par le membre à l'inscription, et on vérifie l'unicité à ce moment.

son email ?

ça peut changer, ça.

 
Et si je veux changer de mail ?

c'est pas faux.

Choisi ? Comme sur un forome ? Genre y a des "kevin22" et des "NightCrawler_75" ? Et pour l'unicité, si le truc est déjà pris, vous faites quoi, vous demandez au gars d'en choisir un autre ?
Au final, ce que je veux dire, c'est que soit t'as un truc non auto-généré (comme ça a l'air d'être le cas chez toi) mais avec les contraintes que ça entraîne lors de la création du compte (caractères interdits, longueur max, etc...), soit t'as un truc auto-généré mais dans ce cas pas pratique en utilisation de clé étrangère.
'fin ch'ais pas, je trouve que la problématique des clés naturelles s'applique justement assez mal au domaine des noms/logins

 
ya pas de "chez moi".
Et je suis plutôt d'accord avec tes remarques, d'où ma question "Membres de quoi?" à macgawel
Je proposais juste une solution possible, comme il disait ne pas en voir.

(...et moi je me fais pas chier avec les utilisateurs, je récupère tout d'un SSO et un LDAP que je ne gère pas moi-même )

Le principe du login n'est valable que dans certains cas.
Si c'est une table des membres d'une association, il n'y a pas (en tout cas pas toujours) de login...

copy on write

Ah, c'est le "on" qui m'a induit en erreur

Ah oué OK

Tu peux toujours avoir d'autres attributs uniques, tout dépend du public et de ce à quoi sert ta table...mais si tu n'en as pas dans ta table c'est évident qu'il te faut une autre clé fictive...

Pis le login ... on tombe toujours sur un gars qui veut en changer
 
La seule données identifiant quelqu'un qui pourrait être suffisamment unique pour être utilisé en tant que PK non auto-générée, c'est le N° INSEE. Et même ça, j'suis sûr que c'est pas assez fiable (programme de protection des témoins, John Doe, ...)

La seule non, suivant le domaine, mais c'est une possibilité oui - si ton application en a besoin je vois pas l'intérêt d'utiliser autre chose.
Et les connards qui veulent changer de login tu as toujours la solution brute création/modification/suppression pour les modifier...

et tu fais comment avec les travailleurs étrangers ?  
 
non, masi changer de login, je leur répond poliment qu'il peuvent se le mettre au fond à droite

et si un chat veut s'inscrire? zanibook staïle,  il a pas de numéro insee lui
 
 
 

spour ça que j'ai ajouté que c'était pas encore assez fiable !
 
Nan mais sérieux : les PK auto-générée, il n'y a que ça de vrai. Je suis en ce moment même en train de maintenir une appli avec BDD dont les PK sont des PK naturelles. Ben c'est de la merde, rien que de la merde. Vive les AUTO-INDENT !!!!!

Utiliser des clés naturelles n'exclut pas de réfléchir à la conception, c'est un fait.

quoted

Ouais mais apparement, c'est trop dûr pour certains d'écrires 2 procédures pour ça

Ou à la maintenance, si ça se trouve la db est très bien conçue il veut juste pas comprendre comment elle est modelée

http://www.bcarter.com/intsurr1.htm

 
j'adore les commentaires à l'emporte pièce  
c'est pas toujours adapté, mais quand ça l'est , autant l'utiliser  
 
quelle que soit la solution choisie, un peu de reflexion avant , ça fait du bien

 
Le sql c'est plus compliqué que le php.
 

 
Possible aussi.

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.