Discussion :

[vadorequest]

Bonjour,

J'aimerais savoir comment on précise qu'un entier (ou autre décimal/chiffre) est non signé.
Je n'ai pas trouvé de case à cocher, apparemment ça fait partie des propriétés étendues mais je n'ai pas trouvé la mise en application.

Je vous remercie.

[fsmrel]

Bonsoir vadorequest,


On applique le même principe que la dernière fois !




On clique sur « Contrôles standards » :




On saisit la valeur minimum :




C’est propagé jusqu’à la génération du code SQL (contrainte CKC_Artqtestock_Article) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE ARTICLE (
       ArticleId            Int                  Not null,
       TvaId                Int                  Not null,
       ArtReference         Varchar(64)          Not null,
       ArtDesignation       Varchar(64)          Not null,
       ArtPrixHt            Int                  Not null,
       ArtQteStock          Int                  Not null,
    CONSTRAINT ARTICLE_PK PRIMARY KEY (ArticleId),
    CONSTRAINT CKC_Artqtestock_Article CHECK (ArtQteStock >= 0)
) ;

Et voilà le travail. Est-ce bien ce que vous souhaitiez ?

[vadorequest]

Encore une fois, je m'attendais à une case à cocher.

Par contre, j'ai l'impression que dans ce cas, ça génère un Int (non un unsigned int) et que ça rajoute une contrainte de type check.

Mais est-ce que ça va pouvoir dépasser la limite d'un int ? Il me semble que c'est deux choses différentes que de changer le type et rajouter un check.

Merci

[fsmrel]

j'ai l'impression que dans ce cas, ça génère un Int (non un unsigned int) et que ça rajoute une contrainte de type check

C’est plus qu’une impression, c’est bien une réalité. C’est une façon de s’assurer qu’une colonne prend pour valeur un entier non négatif.

La norme SQL (disons SQL:1999) prévoit qu’un INTEGER soit dans la plage -2^31 (-2 147 483 648) à 2^31-1 (2 147 483 647), point barre. Aujourd'hui, avec les types de base SQL, vous ne pouvez pas déclarer un entier non signé, contrairement à ce que permet un langage de programmation tel que C.

Maintenant, rien ne vous empêche de définir vos propres types. Toutefois, dans le contexte d’un MCD PowerAMC, ça partira sur la base de la définition d’un domaine (Modèle > Domaines), mais là encore le type généré sera d’une façon ou d’une autre affublé d’une contrainte, selon un mode opératoire propre à votre SGBD. Exemple avec SQL Server, dans lequel le type IntPerso est en réalité un sous-type du type INTEGER qu’on a muni d’une contrainte (rule) interdisant les valeurs négatives, faisant donc que la plage des valeurs sera comprise entre 0 et 2 147 483 647.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE RULE R_IntPerso AS @column >= 0
GO 
CREATE TYPE IntPerso FROM INT
GO
EXECUTE sp_bindrule R_IntPerso, IntPerso
GO
CREATE TABLE ARTICLE (
       ArticleId            INT                  NOT NULL,
       ...                  ...                  ...
       ArtQteStock          IntPerso             NOT NULL,

    CONSTRAINT ARTICLE_PK PRIMARY KEY (ArticleId)
) ;

Si vous voulez une valeur supérieure à 2 147 483 647, vous pouvez — si votre SGBD vous le permet — utiliser le type BIGINT repoussant la valeur maximum à 2^63-1 (9 223 372 036 854 775 807), ce qui en euros représente déjà une belle somme .

[vadorequest]

En fait j'en étais sûr, mais j'ai préféré prendre des gants :p

Je pensais que le SGBD gérait les valeurs non signées par contre, il m'est inutile d'avoir une contrainte check supplémentaire pour une valeur auto_increment (ID), à part ralentir l'insertion ça n'arrivera jamais.

Merci de ton aide !