Reprise du message précédent :
attention pour la sensibilité à la casse de CHAR et VARCHAR
 
même sans l'attribut BINARY on peut y stocker des majuscules/minuscules mais elles ne seront pas prises en compte au niveau des recherches (et des recherches uniquement).

 
Non, la comparaison des deux chaînes retourne FALSE,
 
Par contre tu peux toujours utiliser chop() pour enlever les espaces de fin de chaîne.

J'ai fait un test sous MySQL avec un champ CHAR(32) dans lequel j'ai inséré la chaîne bonjour. J'ai fait un appel à la base puis j'ai comparé la chaîne "MySQL" à "bonjour". Elles sont équivalentes, je n'ai pas une chaîne de longueur "32" soit "bonjour              " etc...
 
Si tu fais un strlen($row->machaine)==32 c'est "FALSE".
 
&  
 
$row->machaine=="bonjour" c'est TRUE.

oki oki...
 
une autre questiong : il vaut mieux avoir des tables avec des trucs redondants (???), avec des memes données dans plusieurs tables pour pas devoir faire plusieurs requetes, ou vaut il mieux avoir un minimum de données par table, mais alors devoir faire plusieurs appels à la base ?

Euh, non tu n'as pas à avoir des redondances entre tes tables, juste des références (liaisons) entre tables si nécessaire.
 
C'est difficile de te dire comment optimiser tes tables, cela dépend vraiment de ton projet.
 
Un super bouquin sur MySQL (+php pour la nécessité) : Pratique de MySQL et PHP de chez O'Reilly (-> c'est bien  plus qu'une simple traduction de la doc MySQL, c'est très bien fait à mon goût, comme tout les bouquins de chez O'Reilly que j'ai pu parcourir).
 
http://www.oreilly.fr/catalogue/mysql_php.html

POur la page ou on affiche les réponses d'un sujet, comment on fais pour récupérer le profil du poster
 
jointure ou alors une boucle while avec un query
 
ou une autre méthose ?
 
Quelle est la meilleur au nivo de l'optimisation

La jointure est plus rapide.
Comme ça, si tu as 1 personne qui va poster 15 messages affiché par ta page, tu fais pas 15 fois la même requête.

pour la diférence char/varchar, c'est une différence au niveau stockage des donnés. Un char(255) va prendre 255 caractères dans la table même si la donée a besoin que d'une.
Par conte, un varchar(255) lui ne va utilisé que la place minimale nécessaire à al sauvegarde du texte. (la chaine "a" ne va prendre la place que d'un seul caractère au niveau du stockage)
Un char(n) est plus rapide qu'un varchar(n) pour tout ce qui est lecture/ecriture du contenu du champ mais en contre partie, la place utilisé pour le stockage est plus important:

• Pour la lecture, le dépalacement d'un bout à l'autre du champs est d'une taille fixe.
• Pour l'écriture, la taille du champs ne change pas en fonction de la taille du contenu ce qui permet de ne aps avoir besoin de déplacer l'ensemble des valeur de la ligne

 
En fait tout dépend de l'utilisation de tes tables :
 
- Si informatique de type transactionnelle (par exemple rentrer les opérations de guichet pour une banque) => il y a nécessité de mettre à jour le plus rapidement possible la base de données. Les redondances doivent être évitées au maximum, pour éviter d'avoir à mettre à jour plusieurs fois la même donnée (sans parler d'éviter les oublis )  
 
- Si informatique de type décisionnelle (type datawarehouse par exemple) les besoins ne sont pas les mêmes : les données ne sont mises à jour qu'une fois par mois / semaine par exemple, et ce que l'utilisateur demande, ce sont des tableaux de synthèse concernant ses données => dans ce cas les redondances sont conseillées pour avoir de meilleures performances lors des requêtes qui portent souvent sur plusieurs centaines de milliers , voire millions, de lignes.

[edtdd]--Message édité par irulan--[/edtdd]

 
donc voici pour moi :  
[i]#
# Structure de la table `messages`
#
 
CREATE TABLE messages (
  Idm bigint(6) NOT NULL auto_increment,
  Date varchar(30) NOT NULL default '',
  Pseudo varchar(40) NOT NULL default '',
  Texte longtext NOT NULL,
  Idr smallint(2) NOT NULL default '0',
  Ids mediumint(4) NOT NULL default '0',
  Icone varchar(4) NOT NULL default '',
  PRIMARY KEY  (Idm)
) TYPE=MyISAM;
# --------------------------------------------------------
 
#
# Structure de la table `rubriques`
#
 
CREATE TABLE rubriques (
  Idr smallint(2) NOT NULL auto_increment,
  Rubrique varchar(30) NOT NULL default '',
  Description mediumtext NOT NULL,
  PRIMARY KEY  (Idr)
) TYPE=MyISAM;
# --------------------------------------------------------
 
#
# Structure de la table `sujets`
#
 
CREATE TABLE sujets (
  Ids mediumint(4) NOT NULL auto_increment,
  Date varchar(30) NOT NULL default '',
  Pseudo varchar(40) NOT NULL default '',
  Sujet varchar(60) NOT NULL default '',
  Idr smallint(2) NOT NULL default '0',
  Vues mediumint(4) NOT NULL default '0',
  Last_update varchar(30) NOT NULL default '',
  PRIMARY KEY  (Ids)
) TYPE=MyISAM;
# --------------------------------------------------------
 
#
# Structure de la table `users`
#
 
CREATE TABLE users (
  idu mediumint(4) NOT NULL auto_increment,
  pseudo varchar(40) NOT NULL default '',
  mot_de_passe varchar(6) NOT NULL default '',
  email varchar(50) NOT NULL default '',
  date_inscript varchar(30) NOT NULL default '',
  ville varchar(40) NOT NULL default '',
  passions text NOT NULL,
  nombre_post mediumint(4) NOT NULL default '0',
  site varchar(60) NOT NULL default '',
  PRIMARY KEY  (idu)
) TYPE=MyISAM;
 
Joce m'a déjà dit que c'était pas optimisé, mais je voudrais avoir plus de détails.
 
ps : voilà un message d'erreur que je viens d'optenir :  
Can't create a new thread (errno 11). If you are not out of available memory, you can consult the manual for a possible OS-dependent bug
Entre "MySQL est en vacances" et ca vous préférez quoi ?
PS : Marc est demandé à l'accueil pour corriger le problème

oloide > il faudrait rajouter dans tes tables de sujets et de messages un index pour la date, car je suppose que tu affiches justement en triant par la date ...
 
sur le forum interne dont je m'occupe, il y a environ un millier de messages (ok, 309 sujets et 1191 réponses précisément ) et ça tourne nickel.
 
moi j'ai défini mes index avec primary key (id, date). dites moi si c'est mal, j'ai fait ça quand je découvrais mysql

Salut !!!!
 
Zallez ptetre pouvoir m'aider !!!
 
Je débute en PHP/MYSQL et c'est la 1ere fois que je cré ma propre table !
 
Cette table sert a stocker du texte + divers chose pour mon site que je suis en train de faire.
 
La voici :
 
CREATE TABLE drivers (
  id int(11) NOT NULL auto_increment,
  type longtext,
  marque longtext,
  modele longtext,
  plateforme longtext,
  version tinytext,
  taille int(11) default NULL,
  url longtext,
  nb int(11) NOT NULL default '0',
  date date NOT NULL default '0000-00-00',
  description text NOT NULL,
  titre text NOT NULL,
  title tinytext NOT NULL,
  commentaire text NOT NULL,
  UNIQUE KEY id (id)
) TYPE=MyISAM;
 
Rien que par la structure, vous en pensez quoi ?

kyle > y a vachement trop de texte dans ta table, elle va gonfler gonfler...
 
tu devrais peut être séparer les données qui ne sont pas indispensables de manière à les joindre uniquement si besoin est.
 
maintenant ça dépend surtout de ce que tu va faire des données..

[edtdd]--Message édité par Sh@rdar--[/edtdd]

oloide > comme j'ai écris plus haut, laisse tomber les varchar pour du char en ciblant au plus près la longeur de chaine.
 
bigint idem, les gros entier sont lourds à traiter et utiles uniquement pour un nombre de msg énorme (surtout en unsigned)
 
pour tes entier si tu n'utilises pas de négatifs, toujours activer le unsigned, tu pourras stocker deux fois plus de nombres.

youdontcare a écrit a écrit : oloide > il faudrait rajouter dans tes tables de sujets et de messages un index pour la date, car je suppose que tu affiches justement en triant par la date ...   sur le forum interne dont je m'occupe, il y a environ un millier de messages (ok, 309 sujets et 1191 réponses précisément ) et ça tourne nickel.   moi j'ai défini mes index avec primary key (id, date). dites moi si c'est mal, j'ai fait ça quand je découvrais mysql

 
tu as défini deux primary key par table !
 
je ne comprend pas à quoi ça sert de définir des key, des index... les bouquins que j'ai sur php/mysql ne disent rien de précis là dessus !
 
je cite :  
l'attribut primary_key définit une clé d'index primaire. Chaque table peut comporter au maximum une clé d'index primaire...
ou bien :
L'attribut unique_key définit une clé d'index...
 
bref, c'est bien beau tout ça mais à quoi ça sert ???

pareil, j'ai eu du mal à trouver de la doc concrète là-dessus. par contre j'ai plus les adresses en tête ...
 
la primary key te sert à identifier de manière unique telle entrée, et aussi récupérer cette entrée très rapidement (sans avoir à parcourir toute la table). la terminologie key/index je crois que c'est un peu la même chose (corrigez-moi si je me trompe) ... d'ailleurs je vais arrêter de parler de trucs dont je suis pas sûr
 
quand tu spécifies un index sur tel champ de ta table, la base de donnée créé une structure qui lui permet d'accéder plus rapidement aux données (en général un arbre binaire).
 
par ex avec ta table de messages : quand tu demandes l'affichage des messages plus vieux que le 15 janvier, mysql n'a aucun moyen de savoir quelles entrées remplissent ce critère. donc il parse toute la table pour trouver. c'est lent.
 
si tu rajoutes un index sur ce champ, les données sont maintenant triées en interne, par date. avec un arbre binaire, il suffit de remonter l'arbre jusqu'à tomber sur la branche dont la date est inférieure au 15 janvier. plus sortir tous les fistons de la branche.  
 
donc si tu as une table de 300000 entrées, dans le premier cas, mysql va faire 300000 opérations (parser tous les champs, comparer la date). dans le second cas, beaucoup beaucoup moins.
 
//
 
ceci dit, oui j'ai deux clés primaires. est-ce choquant ? oui. est-ce que ça marche ? oui. bref ...

 
y a de la bonne doc la dedans !

pourquoi lorsque je modifie un varchar(40) en var(40) par exemple, la modification ne se fait pas : varchar revient !
 
sinon, c'est vrais qu'en limitant les types au minimum et en créant intelligement des index, les requêtes sont plus rapides et ceci pour la même taille des fichiers de la bdd.

tu dois passer ton varchar en char, t'es sur de pas avoir fait d'erreur ?

 
Pas tout à fait exact : les index occupent de la place sur le disque. Cela dit la taille des tables proprement dite ne varie pas, c'est exact.

 
Voici le genre de données qu'il y aura :
 
INSERT INTO drivers VALUES ( '30', 'graphique', 'ati', 'all_in_wonder_128', 'Windows \r\n\r\n95', '4.12.6269', '4', 'http://www.kylewebsite.com/zip/ati/all_in_wonder_128_95.zip', '1', '2001-10-07', '<span \r\n\r\nclass=\"principal\">\r\nChip graphique : <b>Rage 128</b><br> \r\nPort : <b>AGP 2X/4X</b><br> \r\nMémoire : <b>32Mo SDRam/16Mo \r\n\r\nSDRam</b><br> \r\nEntrée/Sortie vidéo : <b>VGA/TV/Video</b><br>\r\nTuner TV - acquisition Mpeg 2\r\n</span>', '<span \r\n\r\nclass=\"titre\">ATI All In Wonder 128</span><br><br>', 'All In Wonder 128', 'Ne pas utiliser avec les cartes : Rage Fury Maxx et Rage Fury Pro Vivo';

kyle > tu affiches toujours les lignes de la même façon ? alors je te conseille le CONCAT (cf plus haut pour exemple) ça te permettra de mettre uniquement les variables dans la table de de n'ajouter le code HTML qu'au moment de générer la page.

Je viens de me renseigner pour le Concat, et donc, ce n'est pas ce qu'il me faut, car le texte ne sera pas de la meme forme plus tard.
 
Par contre, au niveau de ma table, ce ne serais pas mieux d'utiliser des Varchars au lieu de Text ?

 
j'ai fait une erreure de frappe en écrivant le message !
 
non, je ne suis pas trompé car j'utilise PhpMyADMIN pour modifier mes tables.
 
Je change le VARCHAR(40) en CHAR(40), je valide et hop! je regarde dans les propriétés des tables : il y a VARCHAR(40) !!!

j'ai déjà eu le pb, mais ça marchait en modifiant le VARCHAR à la création d'une nouvelle table
 
tu fais un dump, tu modifie la ligne de création du champ et tu balance la sauce ça devrait aller
 
peut être un bug  

up !

 
avec varchar tu es limité à 256 caractéres mais c'est vrai que si tu dois utiliser moins de 256 caractéres ça prend moins de place (texte => logeur + 2 octet alors que varchar => longeur + 1 octet)

Merci du conseil !

up !

Sh@rdar pkoi tu stockes tes messages dans un champs mediumblob et pas text ? C'est uniquement pour faire des recherches case-sensitives ?

au début c'était pour implémenter un moteur de recherche avec un option "case sensitive"  
 
après j'ai pas eu le courage de le faire..  
 
purée il date ce topic je pensais pas qu'il remonterait un jour

 
   
là je ne suis pas trop d'accord avec toi.  D'ailleur, je trouve bizarre que tu dises "non", alors que toi même tu le fais
Heureusement que tu atténues ton propos en disant que ça dépend vraiment du projet
-------------------------------------------------------------
 
qd tu crées ta bd, tu la crées en 3ième forme normale (pas de redondance).
Puis pour l'optimiser, tu crées des redondances en fonction de l'utilisation que tu en fais (voir msg d'irulan).  
 
Ex : mettre dans la table message le login de la personne qui a posté un message en plus de son id (qui "pointe" vers la table user).  Pour une raison simple : ça te permet d'afficher la liste des messages et le lien vers le profil de l'utilisateur en une seule requête.  
Evidemment la redondnace peut créer des annomalies et prend plus de temps lors des updates, mais étant donné que pour un forum on affiche plus souvent que l'on update/insert, ça ne pose pas de gros problèmes...
 
enfin, là je n'ai rien dis de nouveau
 
Sinon, je dirais que l'optimisation passe par plusieurs étapes :
- la conception des tables (ex spécifique pour des catégories : http://membres.lycos.fr/sqlpro/Tree/SQL_tree.htm, hé oui ça peut aller très loin parfois !!), bien penser ses tables.
- le bon choix des types d'attributs ( http://www.phpinfo.net/?p=articles [...] tion-mysql )
- établir des index en fonction des querys
- optimiser les querys (pas besoin d'un select * si on ne veut retirer qu'un attribut)
- créer une redondance pour booster le tout en réfléchissant aux conséquences.

[jfdsdjhfuetppo]--Message édité par ethernal--[/jfdsdjhfuetppo]

Sh@rdar tu dois avoir plein de nouveaux tuyaux a ajouter si c topic est si vieux nan ?    
@+

ouais, va falloir que je compile tout ça  

I'm still waiting...

je crois que tu va devoir attendre encore un moment    
en fait à la création du topic je faisais pas du tout les mêmes applis donc ma manièrede bosser à changer.
 
je suis en train de me poser une question :  
 
à partir de combien de requête UPDATE/INSERT ça devient plus rapide de lire la base plutôt que de faire un script pour enregistrer les infos dans une page HTML ??

ben c po moi qui va te repondre c'est trop metaphysique comme question   ...

un ptit   pour la route
 
si jamais quelqu'un a des infos à fair partager