Hello,  
 
récemment je regarde le schéma bdd d'une appli, et là je vois que tous les PK sont de type integer. Alors je m'insurge, en me disant que ça consomme inutilement de l'espace disque !
 
On m'a répondu que niveau performance, il valait mieux n'utiliser que des integer : si par exemple tu veux balancer des données dans un champ de type tinyint, avant de balancer l'instruction, le processeur doit attendre que le "mot" processeur soit rempli. Il est plus vite rempli si tu utilises des integer plutôt que des tinyint, donc ça va plus vite.
 
Est-ce vrai ? (je sais pas si je suis très clair ...)

1/ le place perdue doit être de l'ordre de 1%
2/ deplus, en SGBD, on parle en PAGES et non en OCTETS. Ainsi, c'est pas parceque tu gagnes 10 octets par ligne que tu gagneras forcément en espace mémoire (c'est plus facile de traîter des blocs de 256 octets par exemple que tantôt 100 octets, tantôt 400 octets quand on a des champs de taille variable)
3/ niveau performances pures et dûr, entre INT et TINYINT, même combat : c'est de toute façon un registre 32 bits (voir 64) qui va le traîter.
4/ Il ne fait jamais utiliser ni INT ni TINYINT, mais NUMBER, qui certes est bien plus gros, mais garanti l'impossibilité de dépasser la valeur maximale (à moins d'énumérer les atomes constituant le système solaire)
 
Enfin, pour terminer :
http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0
 
=> C'est pas à toi de te soucier des performances liées à la représentation interne des données de ta base : toi tu te contentes de stocker les informations dont tu as besoin, d'une façon à la fois la plus simple et la plus évolutive possible. Si ensuite tu as de réels problèmes de performances, tu as toujours la possibilité de faire venir un DBA qui saura améliorer les performances de l'orde de 1 pour 10 sans toucher aux types utilisés, ou simplement changer le matos du serveur. Si tu veux vraiment avoir des perfs optimales, tu bosses à l'ancienne dans un fichier plat binaire. Un SGBD c'est là pour gérer tes données, donc laisse-le faire, il fera toujours mieux que toi.

 
Concernant le fichier plat, j'emets quelques reserves

carrément pas. en termes d'IO, y'a absolument rien de plus performant qu'un fichier plat à pas fixe.
 
"je veux lire le 13465° enregistrement"
=> OK, seek(sizeof(mastruct) * 13465)
Ensuite fprintf(mastruct) et freadf(mastruct) y'a quand même rien de plus performant... si tu veux améliorer encore les perfs, du peux bosser avec un array de ta structure afin de gérer un buffer de cache (et donc lire/écrire plusieurs records d'un coup)
 
Ensuite, pour ce qui est de faire des, jointures et autres, ça je dis pas, mais à ce moment, on utilise un SGBD, et on laisse de côté l'aspect "représentation des données"

Bon donc, si je suis bien tu me dis de mettre des NUMBER partout.
 
Et si je suis bien tu me dis qu'un NUMBER ou un TINYINT ça changera rien de chez rien aux perf.
 
Je susi bien ?  
 
Pour le fait de faire venir un DBA si j'ai un pbl de perf ... je bosse dans la recherche publique donc  bon ... je préfère m'en soucier un peu ^^

=> je dis pas que les perfs seront "identiques". mais par contre, la différence de perfs sera absolument minime, et que simplement appeler un DBA pour une demi-journée permet généralement de corriger des pb de perfs bien plus gros...

Alors autant tu as raison, un expert me trouvera sans peine des problèmes plus importants, autant j'aime bien savoir pour le plaisir de savoir
 
Si par exemple je suis sûr sûr sûr et archi sûr que maintenant et dans l'avenir je n'aurai pas plus de 100 lignes dans une table, mettre la PK en tinyint fait gagner quelques millisecondes ? Et dans ce cas, pourquoi ?
(je sais je suis lourd )

Je ne suis pas convaincu DU TOUT du gain. Du moins, pas qu'il se chiffre en milli-secondes. Pour la simple et bonne raison que de toute façon tu passes par un index, et que je doute que l'index reprenne le type du champ.
Dans tout les cas, comme je disais, ce type de considérations ne sont pas à prendre par le dev, ni même par le DBA.
Par contre, utiliser des index organisés en cluster, partionner les tables, vérifier la façon dont sont mises à jours les statistiques des tables et des index, vérifier la répartition des tablespace sur les disques, etc. sont autant de choses qui peuvent multiplier (ou diviser) par 10 les performances globales de l'application.
 
Le meilleur exemple, c'est avec Oracle, où plus d'une personne a été dans ce cas : la même requête, écrite en intervertissant deux noms de tables (sans pourtant changer la requête) qui passe de 1h d'exécution à 2 millisecondes, ça oui, c'est ce type d'optimisations qui changent tout. Le même genre de gains peuvent être obtenus à vérifiant la mise à jour des stats d'un index, afin de faire un range-scan sur un index unique plutôt qu'un full-scan sur les données, parceque le SGBD se heurte à un index pollué...

Merci pour cette réponse
Du coup ça m'amène à des questions sur les index, mais je vais plutôt utiliser ton thread pour ça.

+1; un simple règlage de stats avec ORA et une requête passa de 20min à <1sec. Et encore, la requête d'origine avait été (ça m'épate) bien torchée par Weblogic, sans quoi c'était pire - une simple interversion dans les jointures et c'était encore plus la cata.
 
Pas la peine de se prendre la tête d'emblée avec des micro-optimisations.