Discussion :

[Drone]

Bonjour,
J'ai un champ qui doit contenir des entiers inférieur à 990.
Je ne peux donc lui mettre un type TINYINT qui j'ai cru comprendre ne dépasse pas les entiers de + de 255.

Ce qui me gêne c'est que sur 40000 données de ce champs, seulement 200 contiennent un entier supérieur à 100, tout le reste se trouve entre 970 et 990

J'utilise le type SMALLINT qui me coûte 2octets et j'aimerais savoir si il y a moyen que mes champs qui contiennent un entier de 100 n'utilisent automatiquement dans SQL qu'un seul octet ?

Une question hors sujet : l'option taille valeurs pour un entier sert juste à limiter le champ mais le nombre d'octet lui ne change pas ? même si par exemple un SMALLINT est limité a 2 chiffres ?

Merci.

[CinePhil]

Ton ordinateur a t-il 30 ans pour que tu sois à la chasse aux octets à ce point ?

Puisque les valeurs peuvent aller jusqu'à 990, va pour le SMALLINT ! Ça te fait 40 000 octets de plus, soit 39 ko. C'est pas la mer à boire quand même !

[Drone]

Je pensais bien que pour le cas que je soumet vous me trouveriez pointilleux et j'en suis désolé.
Ce qui m'intéresse c'est de savoir diminuer mes octets dynamiquement suivant la valeur du champ, que si par exemple mon champ à une valeur plus basse que 256 alors le type de mon champs soit égal à 1octet soit tinyInt, et faire cette opération automatiquement dans mon serveur de base de donnée.

Merci pour votre réponse.

[Madfrix]

bonjour,

c'est impossible. A un champ correspond un unique type de données

[Drone]

Bonsoir, merci pour la réponse.

Est il possible d'avoir un champ qui contient deux autres champs ? l'un avec un type smallint et l'autre avec un tinyint ?

Et j'ai une idée surement fausse.. un champ de type smallint, même s'il ne contient rien il aura dans chaque nouvel enregistrement un poid de 2 octet ?

Parce que sinon je pensais faire un déclencheur du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
CREATE TRIGGER AjoutCP AFTER INSERT ON ville
FOR EACH ROW
BEGIN
 
IF (NEW.CP < 256 ) THEN
BEGIN
 
DECLARE @ID int
DECLARE @CP tinyint
SET @ID = NEW.ID
SET @CP = NEW.CP
 
UPDATE ville
SET CP = '', CP_tinylInt = @CP
WHERE id = @ID
 
ENDIF
 
END

Pour l'explication, ma table contiendrait deux champ CP, un champ CP de type smallint et un champ CP_tinyInt de type tinyint.
Si lors d'un nouvel enregistrement la valeur du champ est inférieur à 256, alors je la déplace dans le champ CP_tinyInt.

Maintenant je pense que c'est nul car un champ vide à toujours le poid de son type n'est ce pas ?

Merci.

[CinePhil]

Je pense effectivement qu'une colonne (et pas champ !) occupera l'espace pour lequel elle est prévue, qu'il y ait une valeur ou non, mais ton truc pour le coup reviendrait à alourdir la BDD puisqu'il y aurait deux colonnes au lieu d'une. Sans compter l'exécution du trigger qui est plus longue qu'un simple insert.

[vmolines]

Même si je comprends que vous vouliez bien faire, je suis de l'avis de CinePhil. Cet octet de plus par ligne ne devrait pas vous poser de problème de performance ou d'espace de volumétrie.

Je pense qu'ailleurs dans votre modélisation, vous devriez avoir matière à optimisation pour des gains plus significatifs.

[Drone]

Bonjour,
je suis d'accord avec vous, ce n'était qu'un jeu pour moi d'essayer de récupérer un octet. De même qu'un trigger c'est lourd, mais je voulais tester.

Je me suis résolu à plus simple, même si au final j'ai du utiliser des varchar...

Faire un requête php qui suivant la taille de la donnée, insère la donnée dans une table fille qui contiendrait un champ smallint.

Et lors d'un select appeler la mère et la fille.. enfin c'est vraiment bidouiller pour pas grand chose j'en suis conscient.

Merci tout de même de l'intérêt que vous avez porté à ce post.

[CinePhil]

Je me suis résolu à plus simple, même si au final j'ai du utiliser des varchar...

Euh... pour le coup, adieu les économies !

Un VARCHAR(3) occupe jusqu'à 4 octets ! 1 par caractère + 1 pour la taille de la chaîne.

Et il faudrait savoir si votre colonne stocke une donnée de type numérique (identifiant, quantité...) ou alphanumérique (code, numéro, référence, matricule...). Si vous devez ensuite transformer la chaîne de caractères en nombre pour faire des calculs dessus, c'est un coût supplémentaire à l'exécution qui se multiplie par le nombre de lignes traitées !

[Drone]

Et bien ce sont des caractères alphanumérique, sur 40000 données, il doit y en avoir une 20aine qui contienne des lettres, comme pour le smallint c'est rare.
Cependant non je n'ai pas de calcul à faire dessus, juste des insertions et surtout des affichages de la totalité des données, trié etc.. donc plus la donnée est faible mieux je pensais m'en tirer.

Merci pour la précision pour varchar, je suis au courant du L + 1 octet par caractère.

Je pense faire des tables filles.
Car la vérification du type de donnée se fait seulement à l'insertion pour savoir si j'insère sur une table ou un autre.
Ensuite pour l'affichage, je fais une vue sur les deux tables, il n'y a pas de calcul.

Ca me ferait une insert sur la table mère de tout les autres valeurs, puis une requête du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
if (is_string($tab['var']))
$query = "INSERT INTO fille_varchar VALUES ($tab['var'],$tab['id']";
 
else 
{
   if $tab['var']>255
   $query = "INSERT INTO fille_smallint VALUES ($tab['var'],$tab['id']";
   else
   $query = "INSERT INTO fille_tinyint VALUES ($tab['var'],$tab['id']";
}

[Maljuna Kris]

Saluton,
S'il s'agit, fonctionnellement, du même attribut d'une entité du MCD, les requêtes à venir pour tout calcul de groupage nécessiteront de faire une UNION entre les deux tables filles ce qui m'apparaît le contraire du principe KISS, pour un gain assez illusoire.

[CinePhil]

Et, encore une fois, 40 000 lignes, ce n'est rien pour un SGBD !
Alors une seule colonne de type VARCHAR de la taille juste nécessaire, un index dessus et roule ma poule !

[Drone]

Oui je comprend vos avis, merci en tout cas.