Bonjour,
 
j'ai a placer dans une table InnoDB d'une base MySQL des données numériques de types différends (entier, bool, float).
 
Pour minimiser le volume de donner je peux tout mettre dans des champs de type entier (je n'ai besoin que d'une faible précision pour mes float donc je peux les stocker en entier puis les diviser au moment ou je les récupère, soit au niveau de mysql soit du script php derrière).
 
Mon problème est que si je stock tout sur un seul champ qui sera de taille à enregistrer le plus gros enregistrement (dans mon cas un mediumint doit suffire), j'occupe la place d'un mediumint même pour un booléen ou un entier qui aurait tenu dans un tinyint.
 
Je pourrai aussi via une procédure déterminer la taille de mon type de donnée et le placer dans un des champs de type bool, tinyint, smallint ou mediumint et en mettant tous les champs non utilisé pour cet enregistrement à NULL (on se retrouve alors avec autant de champs que de taille possible pour un seul champ utile par enregistrement).
 
Mais est-ce vraiment utile, à savoir, est-ce que mes champs NULL occupent de la place dans ma base ou non ? Parceque gagner quelques bits sur le champs où est placé mon enregistrement mais en perdre avec la création d'autres champs NULL à coté, c'est pas bien malin.
 
Quelqu'un saurai-t-il me dire si en terme de volume de donnée la seconde solution est intéressante ou non ?
 
Merci de m'éclairer.
 
PS :
 
Bon, bizarrement il semblerait qu'il n'y ai aucune différence, à ma grande surprise...
 
Ou alors j'ai pas bien compris ce que j'ai fait !
 
j'ai créée les 2 tables suivante :

j'ai ensuite créée la procédure stockée suivante :

et je l'ai appelé pour réaliser 40000 enregistrement pour chaque table :

résultat :
 
taille des données : 1 552 ko dans les  2 tables !!!!
 
Ca vous semble logique ?

honnetement c'est complètement débil de concevoir une DB ainsi.  
Tu coinçois des Tables pour tes besoins. Pas au cas ou tu devras stocké tel ou tel type de données.  
 
Si je prends l'exemple d'un SGBD digne de ce nom comme ORACLE, celui-ci que tu encodes une valeur numérique ou null ne prendra pas plus de place car l'espace est de toute façon réservé au niveau des fichiers de données sur lesquels est lié le TABLESPACE de la table.  
Donc je ne sais pas si tu tests est vraiment d'une grande utilité.

c'est peut-être débile, peut-être pas... avant de pouvoir porter un tel jugement il faudrait avoir un peu plus de données sur mon cas pour pouvoir en tirer une telle conclusion (qui est peut-être valable je dis pas, sauf qu'il est évident que tu n'as pas assez d'informations pour pouvoir l'affirmer).
 
Ma table est une sorte de table "générique" où je stocke des données "semblable" du point de vue de mon modèle merise, mais dont le type numérique diffère un peu (il s'agit d'acquisition qui peuvent être analogique, numérique ou tout ou rien).
 
C'est pour ça que je m'interroge sur le fait de diviser ces données au sein de ma table suivant leur taille réelle pour gagner en espace de stockage plutôt que de tout mettre dans le type le plus gros, ce qui marcherai à coup sur mais serait assez gourmand.
 
Pour le coup du SGBD digne de ce nom, c'est aussi peu pertinent comme remarque que le coup du "débile", car on ne maitrise pas toujours le choix de son SGDB d'abord, ensuite parceque j'imagine qu'avec les progrès constant de Mysql pour rattraper son retard, le fossé qui le sépare des autres SGDB "digne de ce nom" diminue de façon à ce qu'il soit tout à fait adapté à certains besoins.
 
D'après ce que tu sembles dire sur Oracle, la valeur null occupe de toute façon la place définit par le type du champs. C'était ma question pour Mysql, ce qui semble différend puisque sinon ma seconde table devrait être beaucoup plus grande que la première.
 
Ma question ne semble donc pas illogique, ce qui l'est par contre à mes yeux, c'est l'égalité au kilo-octet pret de mes 40000 enregistrements, avec un seul champ mediumint systématiquement remplit ou avec un seul champ remplit parmis 4 de taille différentes et infférieur ou égal à celui de la première table.
 
Cette taille de 1552 ko m'est donné par phpmyadmin dans sa version 2.10.1 si ça peut aider.

a priori c'est logique, que ce soit null ou une autre valeur pour ce genre de type il va résever de toute facon la mémoire pour pouvoire rapidement se déplacer par offset, a priori les seuls types de champs pour lesquels la valeur maximale de mémoire n'est pas allouée sont les varchar et les raw, blob et consorts.
mais je ne me suis jamais documenté profondément sur le sujet.

 
ce qui serait logique, si la valeur null occupait de toute façon l'espace définit par le type du champ, ce serait que ma 2nde table occupe 1 bool + 1 tinyint +1 smallitn + 1 mediumint par enregistrement (+ l'index).
 
Et donc pour 40000 enregistrements, cette table devraient être beaucoup plus grande que celle ou je n'occupe qu'un mediumint par enregistrement.
 
Etant donné l'égalité exacte de la taille de mes tables, j'ai un doute sur la fiabilité de cette info.

sorry j'avais lu le post en diagonale,
tu as parcouru des docs sur le net du style http://dev.mysql.com/doc/refman/5. [...] ecord.html ?

Plusieurs choses :
1/ Lire mon coup de gueule au début du premier lien de ma signature (si tu fais pas confiances à ton SGBD pour gérer correctement les données, gère-les toi-même, cherche pas à faire n'importe quoi avec ton SGBD)
2/ Dérivé du premier : la seule chose logique, sûr et connue, c'est que le SGBD gérant pour toi les données, tu n'as ni à te soucier de comment il fait, ni de ce qu'il fait, ni de comment faire mieux (tu pourras pas de toute façon), ni avoir d'explication "rationnelle" sur ce genre de tests.
3/ Une table ne grossi pas d'octet en octet selon les besoins, mais de x Ko par x Ko, voir de x% en x%. Ceci pour une raison évidente : t'as deux tables qui grossissent en même temps, si elles bouffent chacune exactement ce dont elles ont besoin à chaque ajout de ligne, alors ton fichier va être complètement fragmenter et les performances vont s'effondrer.
4/ A l'heure où 1 Go de disque coûte 0,158 €, c'est quoi l'intérêt de gagner 1 Mo ??? http://www.rue-montgallet.com/prix [...] Caviar-SE/ (le pire en plus, c'est que le meilleur rapport taille/prix, c'est quand même un WD Caviar Special Edition, genre le truc qui tiens la route arf)
 
Par contre, entre lire/écrire des données dans leur format natif, ou lire/écrire des données dans un format transformé, ça c'est clair que ça consomme un max de CPU. Et pas de chance, entre CPU et HD, c'est le HD qui a le plus baissé ces dernieres années, c'est donc les cycles CPU qui doivent être impérativement économisés.

Merci pour la réponse
 
pour le 1/, je fais confiance à mon SGDB pour la fiabilité de mes données, mais pas forcément aux outils qui le gère : phpmyadmin m'affiche par exemple une valeur erronée pour le nombre d'enregistrement des tables (39800 et des brouettes pour l'une et 40400 et d'autres brouettes pour la seconde, sachant que je n'ai vraiment insérer que 40000 enregistrement dans chacune)
 
Il n'y a aucune raison que la taille occupé par mes données soit exacte dans les 2 cas, plus l'approximation que je viens de cité, je mets forcément en doute ce résultat.
 
3/ c'est la vrai réponse à ma question, pour éviter de fragmenter les infos, le SGDB réserve l'espace par "paquet", du coup il est maintenant tout à fait logique que l'espace occupé par mes tables (et non mes données) puisse être identique.
 
4/ ce que tu dis est vrai pour un pc/serveurs que tu gères chez toi, pour un hébergement, tu maitrise pas beaucoup le volume de stockage par rapport aux autres prestations qui font partie du même service d'hébergement.  
C'est comme les Pc portables, les grands écrans sont toujours accompagnés du matériel haut de gamme, et il est quasi impossible d'avoir un grand écran avec une configuration modeste qui peut suffire à nos besoin, c'est donc soit un grand écran et de la mémoire/cpu/carte graphique sur dimensionnés pour un coup lui aussi sur dimensionné, soit une petite config adaptée mais avec un écran limité.
 
Pour les hébergements, c'est pareil, pour avoir un volume de stockage important, je suis obligé de prendre des options inutiles qui augmente le tarif de l'hébergement au delà du prix du Go supplémentaire.
 
Pour cette table, la prévision du volume de donnée est de [5 ; 20] clients *  [1000 ; 10000] appareils * [10 ; 100] enregistrements journaliers = [18250000 ; 7300000000] enregistrements / an.
 
A ce niveau l'optimisation de l'espace disque compte ! Et étant donnée que peu de personne viendront consulter ces données ([5 ; 20] clients (client = entreprise avec quelques personnes habilités à la consultation) de prévu pour le moment, le prix de l'espace disque justifie ce genre d'optimisation au dépend du CPU dont la consommation sera faible.
 
En tout cas, merci de m'avoir éclairé sur ce point sur les SGDB.