Reprise du message précédent :
ceci les locks des jointures ne sont pas si emmerdant si le handle fait du row locking au lieu de faire du table locking

Il n'empêche que même sous Oralce, où on fait des row locking j'ai jamais vu la moindre clé étrangère, à à mes début, chaque fois que j'ai voulu en mettre, on m'a ligotté dans la cave pour m'empêcher de la mettre

perso j'en ai jamais mis une seule non plus
A la limite ca peut être utile en phase de développement pour détecter des conneries éventuelles que tu pourrais faire, mais une fois la phase de dév finie, je serais pour les virer
Et j'ai jamais été très fan des ON DELETE / ON UPDATE, je préfère le faire à la main

 
pas de requetes imbriquées. Stou

 
tu sais pas lire ..... ? Les requêtes imbriquées sont dispo depuis la version 4.1.    
 
donc pas d'arguments valable ( mysql power   )

 
 
Hého tu te calmes un peu ?  
Je reste poli, moi...
Ta maman ne t'a jamais appris que les insultes n'étaient pas la meilleure façon de convaincre qqn ?

Non et tu le sais.
 
Mettre un :sarcastic: ou un :lol: à la fin de chaque phrase c'est clairement manquer de respect envers ton interlocuteur. Et d'une manière générale le ton que tu emploies est particulièrement dédaigneux.
 
Maintenant si c'est le seul argument que tu as à avancer pour défendre ta position, c'est bien dommage.

 
ah ouais ?

1) je suis toujours comme ça quand je me réveille au milieu de l'après-midi, c'est à dire tout les week-end, faudra t'y faire
2) non tu n'est pas poli, tu es particulièrement dédaigneux, et tes propos sont limite vaniteux (ça va ensemble de toute façon)
3) je ne t'insulte pas, je te remet à ta place, qui plus est en donnant une explication argumentée, ce qui semble être étrangé à ta façon de faire.

 
Mes arguments, ça fait 2 jours que je les ai présentés
* propreté du modèle de la DB
* evolutivité du modèle de la DB
* intégrité des données
 
mais ces concepts te semblent totalement étrangers donc tu ne veux pas les admettre... A partir de là, plus aucun dialogue n'est possible

Je t'ai déjà expliqué pourquoi tes argument son bon niveau théorique mais pas en pratique.
 
L'intégrité, c'est pas à la base de la gérer, car tu ne peux pas tout gérer.
 
Relation conditionnelles :
 
Tu as une table de matériel.
Si le matériel est en leasing, alors il est associé à un contrat.
Si le matériel n'est pas en leasing, il est associé à une facture.
 
Tu me la fait comment ta relation ? (j'ai bien dit, le matériel porte sur une facture ou un contrat, pas l'inverse)
 
Relation cyclique :
Une table utilisateur. Un utilisateur est rattaché à un groupe.
Un groupe est géré par un utilisateur.
 
Tu fais comment pour insérer le premier utilisateur là ?
 
Donc dans ces cas là, tu gères toutes les contraintes d'intégrités au niveau applicatif, un point c'est tout. Y'a que les porcs qui éclatent leurs contraintes un peu partout.

 
Tu bloques sur le côté "intégrité" en oocultant le 2 principaux : propreté et evolutivité du modèle avec une troisième table (même sans contraintes) : bel exemple de mauvaise foi caractérisée  

Tien justement je me suis demandé s'il n'était pas un multi de Tetra (ou l'inverse)

propreté :
-> je ne vois pas ce qu'il y a de propre à faire des tables de correspondance à tout bout de champ, mise à part si avoir 400 tables dans un modèle tu trouves que c'est pas assez et que 200 de plus c'est très bien
-> évolutivité. ok, parceque toi tu fait évoluer un modèle des données ? et tu trouves que tu bosses proprement ? et en quoi une table de correspondance est plus facile à faire évoluer ? ha, oui, tu rajoute une deuxième table de correspondance pour faire la conrrespondante avec une table table de correspondante que tu a mis en relation, j'ai compris !

 
T'as vraiment rien compris. Mon modèle n'est pas limité au nombre de cat, contrairment au tien. Puisque Hermes veut faire un forum avec plein de cat privé, on peut imaginer que ça peut évoluer au delà de 136 catégories codés en dur  

 
 Hum, propreté du modele c bien quand tu montres sur papier aux decideurs ce que tu as fait. L'evolutivité ça m'etonnerait, rien que les problemes de portage Mysql<->Oracle<->SQL Server<->PostgreSQL a cause de ces techniques ça tombe à l'eau ce que tu dis
 
 Quant à l'integrité : quand ton projet est en cours de developpement et que tu ne peux pas te permettre de tout gerer niveau software alors tu utilises ces techniques te permettant la redondance d'informations et la corruption de ta base.
 
 Mais une fois ton dev terminé, comme ta base sera certainement utilisée via un Frontend ou une interface Web, cela ne sert plus a rien, a moins que tu ne saches pas programmer.
 
 
 Maintenant il est vrai que c plus propre rien que pour pouvoir faire de la retro ingenierie et pour pouvoir, a la suite, developper de nouveaux modules se basant sur ta BDD.
 
 Mais si tu n'as pas le materiel qui va avec, laisses tomber !

136 cat, j'ai du mal à concevoir autant, chuis même pas sur que sur le site de joce, hébergé sur le serveur ppc où il y a pas mal d'autres forum il aie atteind ce chiffre... !
 
A nouveau, dans la théorie, tu as entièrement raison, mais dans la pratique tu as tord.

 
J'ignorais que PPC était le seul canon biblique des codeurs de forum...    
 
Hermes veut faire des cat privés : s'il peut y en avoir au moins une par user, ça risque vite de plafonner.
 
Et pour ce qui est de la pratique, tu n'as aucune idée, pas plus que moi, de ce que veux faire Hermes. Donc tes conseils n'ont aucun poids. Avec une troisième table, il n'y  pas cette limite de 136 cat ce qui laisse un evolutivité totale (plusieurs cat privées par user par exemple).

 
Parceque pour les PM tu gères ça dans des cat distinctes ? Et tu dis que tu sais modéliser ?
 
Arrête ton délire.
 
Et oui, le forum de ppc est un des plus aboutis du marché, largement devant ubb ou autres trucs, mais surtout un de ceux qui héberge les forums les plus fréquentés. donc à partir de là, si je cherche des valeurs "limites" pour gérer un truc, je me base sur l'odre de grandeur remarqué ce forum.

 
Encore la mauvaise foi, c'est pas croyable  
Avec mon modèle, on peut être plusieurs à discuter sur une cat privée avec login/password, rien à voir avec les PM

non, c'est pas de la mauvaise fois, j'essaie de comprendre pourquoi il pourrait y avoir autant de cats privés que d'utilisateurs, y'a un truc qui m'échappe.
 
mise à part pour gérer des pm, je vois pas ce que tu pourrais en faire.

 
Si tu n'as aucune imagination, c'est pas ma faute. Aucune vision à long terme...  
 
Avec mon modèle, il peut y avoir plusieurs users à discuter sur une cat privée avec password, rien à voir avec les PM

et moi je crois que tu rêve trop.
 
putain mais t'es fou ! tu gères la clé de tes post avec un number !
 
mais comment tu fais le jour où tu as plus de 10^38 - 1 posts

 
continue dans la mauvaise foi, tu me fais rigoler

désolé de te parodier

 
Comment fait il ?
 
Perso, je n'ai pas d'apriori sur ce que veut faire Hermes.  
Il peut avoir envie de laisser la possibilité à ses users de pouvoir créer chacun plusieurs catégories privées de discussion, accessible chacune par un password.

 
Si tu te soucies tant de ce que veut faire Hermes, n'oublie pas son but premier: FAIRE UN FORUM RAPIDE EN MYSQL!!!
 
Alors tes considérations théoriques, c'est bien joli mais ca ne tient pas la route dans la pratique.
 
Pour ton info, je suis confronté à se problème en permanence pour le moment, je dois partir d'un modèle conceptuel de DB "idéale" (temporellebi-directionnelle, objet, relationnelle, géographique) et le transformer en modèle physique. Ben la transformation dans le modèle ER type oracle 9, c'est bien, mais si on en reste là, avec des tables splités dans tous les coins, c'est VRAIMENT la merde niveau performance, du coup, t'es obligé de réfléchir pour trouver un algo qui va analyser en profondeur tes tables plutôt que de bêtement applique un modèle meurice ou uml.

 
Hého, reste calme, ici on parle de passer de 2 tables à 3 tables. C'est pas ce j'appelle un modèle compliqué.

C'est une augmentation de 50%.
 
Il ne faut pas regarder les nombres, il faut regarder la proportionalité.

 
Et ? Pour rester dans l'argumentation foireuse à 2 balles : la puissance des machines double tous les ans

la puissance des machines double tous les ans mais un programme mal foutu continuera de tourner moins vite qu'un bien conçu.
 
Maintenant, si tu ne vois pas en quoi passer de 2 à 3 tables est un problème au niveau de la performance dans ce cas, j'ai comme un doute sur le fait que tu aies jamais utilisé la commande EXPLAIN ou un benchmarq pour tester tes requètes...

 
Bon ca suffit le troll ? Tu sais très bien comme moi qu'il ne suffit pas de 2 tables pour faire un forum
 
Il faut minimum :
* 1 table pour les messages
* 1 table pour les topic
* 1 table de cat
* 1 table de user
(+ 1 table pour les relation user-cat)
 
Donc ton argument sur le coup des 50%, il passe subitement à 25% : Laisse moi douter fortement de tes compétences

le problème n'est pas le nombre de tables totales, mais le nombre de tables nécessaires pour effectuer les requètes standards.
 
Mais bon, visiblement ca te dépasse...

Bon je te laisse troller tout seul

ca correspond au catégorie VIP sur ce forum.
J'ai une table séparée qui associé pseudo / cat / forum, avec clé primaire sur pseudo / cat / forum (normal quoi).
Avec ca, je checke à l'entrée d'un pseudo dans une cat si il fait parti de la table VIP (WHERE sur pseudo / cat / forum => index => résultat quasi immédiat), et effectivement je n'ai aucune limitation à part la taille des champs cat et forum, et pas besoin de jointure.
Par contre j'utilise pas de foreign key, ca sert à rien...

Pas mieux. Simple, rapide, portable et évolutif
 
Et contrairement à la solution proposée par MagicBuzz, qui est à la fois moins propre et moins rapide, c'est beaucoup plus pratique pour générer par exemple les divers menus déroulants qui seront utilisés sur le forum pour lister les sections accessibles en fonction des authorisations de chaque user (menu utilisé sur le moteur de recherche, sur la liste des forums et des messages ...). Grâce au fonctionnement en B-Tree il n'y a même pas besoin d'index supplémentaire sur le champ pseudo pour obtenir instantannément la liste des sections privées auquelles un membre X a accès.

yep effectivement pseudo, pseudo / cat et pseudo / cat / forum seront optimisés par l'index B-Tree

le problème de la solution de magic c'est qu'elle n'apporte à mon sens aucun avantage niveau rapidité :
il doit faire un accès à la table membre, je dois faire un accès à la cat VIP => c'est kif kif.
Par contre là où il pert en efficacité c'est qu'il crée une nouvelle colonne relativement grosse (selon le nombre de possibilité), qui va faire pas mal grossir la table inscrit alors que c'est pas necessaire, voire pas conseillé (la table inscrit est énormement solicitée en lecture, donc plus elle est petite et mieux c'est ) : en effet en comparaison aux nombres total de membre, le nombre de ceux qui iront dans des catégories privées c'est peanuts.
Donc par exemple s'il y a 100 personnes ayant accès à une cat privée, sur un total de plus de 50000 membres, ca nous fait 49900 entrée dans la table créé pour rien, et avec aucun gain de perf.
De plus les requètes de l'interface d'admin, pour la solution de magic, seront bcp plus compliquée à mettre en place, et pas forcement optimisées
 
Le choix de créer ou non une nouvelle table pour moi doit être motivé par la necessité par la suite d'avoir besoin à une jointure (pas de jointure pour des SELECT critique niveau perf) et au gain de place. Avec ces deux facteurs tu choisis la structure qui te convient.
 
Le cas échéant, y a aucun interet à rajouter une colonne à la table membre, à part te compliquer la vie (à mon avis).

Tiens, toi qui suis de prêt le développement de MySQL joce il me semble avoir lu qu'il était question de la création d'un nouveau champ de type CHAR, voire de la modification des propriétés de VARCHAR. Tu as des infos là dessus ?
 
Faire une bonne table membres n'est pas évidement sous MySQL dans la mesure où elle contient de nombreux enregistrements de taille non-fixe (adresse email, adresse du site perso, login MSN, éventuellement mot de passe si on ne stocke pas un hash, etc ...) et ne j'arrive pas à déterminer s'il vaut mieux stocker tout ça dans un CHAR, sachant que ca fait une perte de place énorme (moins de 20% des membres doivent renseigner un login MSN ou une URL de site ...), ou dans un VARCHAR, auquel cas on perd les bénéfices d'une table statique (rapidité et facilité à cacher en RAM notamment)
 
Qu'est ce que tu préconises ?

Dynamique pour moi. Les infos dans la table inscrit change très peu, donc le query cache de MySQL 4.x sera très efficace dessus
 
Pour info, table inscrit de HFR en dynamique : 15 542 Ko  
Pour info, table inscrit de HFR en statique : 91 278 Ko
 
Pour le "vrai" varchar, ca ne concerne pas le table handler MyISAM, qui a déjà un vrai varchar, si je me rappelle bien.

l'avantage de la solution de magicbuzz, c'est que, à mon avis, contrairement à ce qu'il me semble que tu penses joce, il ne faut pas faire un acces à la table membres à chaque requete... la valeur "permissions" serait stockée dans un objet "user" qui serait stocké en session... tu le charge donc une seule fois au login, apres c'est ton script qui fait un peu joujou avec les bits...
certes c'est moins évolutif et moins propre, mais ct juste pour clarifier le truc