Discussion :

[jfcollombet]

Bonjour, est-il possible dans SQL Server de limiter la valeur d'un champ d'une table ?

Voici la mienne :



Je souhaiterais que les valeurs attibuées au champ DET_PNET ne puissent pas dépasées 1000.

A noter que les insertion dans cette table sont faite via une application C#.

Merci de m'aiguiller.

[escartefigue]

Bonjour,

Oui c'est possible : ajoutez une contrainte CHECK sur la colonne, les champs, dans une base de données, ça n'existe pas

cf. https://docs.microsoft.com/fr-fr/sql...l-server-ver15

EDIT : si la colonne PNET contient un poids net, le choix d'un type float est probablement inadapté, sauf s'il s'agit de poids énoooooormes et que la valeur décimale importe peu... sinon, remplacez par du decimal.
idem pour les autres colonnes de type FLOAT bien sur

[SQLpro]

Bonjour,

Oui c'est possible : ajoutez une contrainte CHECK sur la colonne, les champs, dans une base de données, ça n'existe pas

cf. https://docs.microsoft.com/fr-fr/sql...l-server-ver15

EDIT : si la colonne PNET contient un poids net, le choix d'un type float est probablement inadapté, sauf s'il s'agit de poids énoooooormes et que la valeur décimale importe peu... sinon, remplacez par du decimal.
idem pour les autres colonnes de type FLOAT bien sur

Pour tout ce qui est mesure physique je préfère le FLOAT, plus rapide dans les calculs !

A +

[Michel.Priori]

Bonjour,

Et j'irais même plus loin que la remarque d'escartefigue (+1 néanmoins)

De manière générale il faut être économe dans le choix des types de données pour ses tables ; il faut choisir le type "juste suffisant".

La logique est simple : les lignes sont stockées dans des pages de 8k. Plus la ligne est "petite", plus il en rentre dans 1 même page, moins on brasse de pages pour obtenir le même résultat.
Dans les phases de test initiales on ne s'en rend pas forcément compte. C'est après, quand il y aura du volume, que ça deviendra évident.

Float :
Un float occupe 4 ou 8 octets ; Dans le cas présent 8
https://docs.microsoft.com/fr-fr/sql...l-server-ver15
Un decimal occupe 5, 9 13 ou 17 octets.
https://docs.microsoft.com/fr-fr/sql...l-server-ver15

==> En adoptant decimal(9,3) au lieu de float, on gagne 3 octets ; vu qu'il y a 3 colonnes, 15 octets (et si on passe à un decimal(10,3), on perd 1 octet )


Nvarchar :
La colonne nvarchar(25) va occuper de 1bit (si null) à 101 octets. Le codage en Nchar ou Nvarchar est en UTF-16 soit 2 ou 4 octets par caractère
https://docs.microsoft.com/fr-fr/sql...l-server-ver15
https://fr.wikipedia.org/wiki/UTF-16
Il faut ajouter 1 octet de contrôle pour marquer, dans le stockage, la fin de la valeur de longueur variable

==> en adoptant varchar(25) la plage d'occupation est de 1 bit (si null) à 26 ; soit 4 fois moins de place qu'en Nvarchar(25)

En imaginant que DET_LOT soit utilisé pour un N° de lot faut voir si un CHAR(n) ne serait pas plus indiqué (on gagne encore 1 octet dans le stockage mais cette colonne occupera un espace fixe pour toutes les lignes (sauf si null, 1 bit)

Datetime :
extrait de la doc : https://docs.microsoft.com/fr-fr/sql...l-server-ver15

Utilisez les types de données time, date, datetime2 et datetimeoffset pour une nouvelle tâche. Ces types s'alignent sur la norme SQL. Ils sont plus portables. time, datetime2 et datetimeoffset offrent une meilleure précision à la seconde. datetimeoffset fournit la prise en charge des fuseaux horaires pour les applications globalement déployées.

Taille de stockage : 8 octet
==> en adoptant smalldatetime on économise 4 octets (2 colonnes => 8 octets)

Mise en application (à valider en fonction des besoins effectifs) :
En supposant que la col DET_LOT occupe, en moyenne, 13 caractères et qu'ils sont pris dans le dictionnaire anglais (s'il y avait du japonais ce serait une autre chose )
actuellement une ligne occupe un peu plus que
4+4+4+8+4+8+8+27+4+8+8 = 87 octets
si tous les changements sont possibles alors on a
4+4+4+5+4+5+5+14+4+4+4 = 57 octets
L'économie de 30 octets à la ligne n'est pas négligeable.
Pour aller plus loin il faudrait ajouter les informations de structure de ligne et d'autres détails pour lesquels on n'a pas de moyen de contrôle car c'est M$ qui fait ce qu'il veut de son stockage.

Je sais ça fait un peu 'épicier' mais ça paye

[SQLpro]

==> en adoptant varchar(25) la plage d'occupation est de 1 bit (si null) à 26 ; soit 4 fois moins de place qu'en Nvarchar(25)

Niet !

varchar et nvarchar s'ils sont NULLs occupent tous deux 2 octets (pour stocker la longueur qui sera de 0 dans ce cas particulier) + 1 bit (de NULL).

A +