Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MS SQL Server Discussion :

Limiter la valeur d'un champ Float


Sujet :

MS SQL Server

  1. #1
    Membre du Club
    Limiter la valeur d'un champ Float
    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.

  2. #2
    Expert éminent sénior
    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

  3. #3
    Rédacteur

    Citation Envoyé par escartefigue Voir le message
    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 +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  4. #4
    Membre expérimenté
    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
    Le savoir est une nourriture qui exige des efforts.

  5. #5
    Rédacteur

    ==> 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 +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

###raw>template_hook.ano_emploi###