Que signifie le caractère UQ__ lors de la création d'une table Sql Server ?

Version imprimable

1 pièce(s) jointe(s)

Bonjour à tous.

J'ai un soucis dans la création des tables dans Sql Server Developper Edition 2017 et SSMS 18. Lorsque je crée une table, dans le dossier clés je vois ce symbole UQ__ suivi du préfixe du nom de la table et d'une suite d'autre caractères. Par Exemple avec la création d'une table tblUsers, j'ai ceci :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 CREATE TABLE tblUsers ( UserId NVARCHAR(20) UNIQUE NOT NULL, UserName NVARCHAR(50) UNIQUE NOT NULL, LoginName NVARCHAR(15) UNIQUE NOT NULL, UserPassword NVARCHAR(15) NOT NULL, UserStatut NVARCHAR(20) NOT NULL, UserRegistDate DATETIME, UserImage IMAGE, ); GO
Une fois le script exécuté, j'ai deux sortes de clé dans le dossier clés
Code:

1 2 3 UQ__tblUsers__C9F28456EFE38E0A UQ__tblUsers__DB8464FF28007620
Illustration
Pièce jointe 526183

pourtant je n'ai crée aucune clé, et bien même que je le fais, j'ai le même problème.

Quelqu'un peut-il m'expliquer ce que cela signifie svp ? et si cela à des conséquences sur le fonction de la base de donnée.

Cordialement.

23/12/2019, 07h39
soazig

Bonjour,
Lorsque tu fais un click droit sur UQ__tblUsers__C9F28456EFE38E0A et que tu choisis quelque chose comme generate create script, qu'est ce que ça te montre ?
Je dirais qu'il s'agit de contrainte d'unicité, car tu as déclaré tes colonnes comme étant uniques mais tu n'as pas nommé la contrainte d'unicité, SQL server l'a fait pour toi avec un nom qui ne te convient pas.
Cordialement
Soazig
23/12/2019, 08h07
soazig

Rebonjour,
De plus vu le nombre de colonnes uniques dans ta table, tu ne devrais pas avoir de mal à définir une clé primaire, c'est toujours mieux.
Cordialement
Soazig
23/12/2019, 13h45
escartefigue

D'ailleurs le nom unique c'est assez peu vraisemblable
Et aussi, le statut gagnerait à être une FK (integer donc) qui pointe vers une table des statuts dans laquelle on trouvera un code, un libellé et éventuellement des dates de début et de fin de validité.
23/12/2019, 21h05
TSAFACK-M

Bonsoir

Merci pour votre intervention.

Bien vue pour le statut dans une table séparée, cela m'avait bien échappé 8-)!

Cordialement.
23/12/2019, 21h31
TSAFACK-M

Bonsoir.

En effet, lorsque je supprime UNIQUE, la table se crée correctement et sans ces clés automatiques.
Mais en spécifiant les champs uniques dans les tables cela ne devrait pas normalement causer ce genre
de problème. Car lorsque je crée la table en mode graphique et avec les mêmes contraintes, il n'y pas
de clé superflue qui se crée dans la table.

Cordialement.

Bonjour,

Il te suffit de nommer tes contraintes, comme cela ce sera plus clair. Une idée de script je n'ai pas pu tester.
Code:

1 2 3 4 5 6 7 8 9 10 11 CREATE TABLE tblUsers ( UserId NVARCHAR(20) constraint UQ_tblUsersUserID UNIQUE NOT NULL, UserName NVARCHAR(50) constraint UQ_tblUsersUserName UNIQUE NOT NULL, LoginName NVARCHAR(15) constraint UQ_tblUsersLoginName UNIQUE NOT NULL, UserPassword NVARCHAR(15) NOT NULL, UserStatut NVARCHAR(20) NOT NULL, UserRegistDate DATETIME, UserImage IMAGE, ); GO
Citation:

Car lorsque je crée la table en mode graphique et avec les mêmes contraintes, il n'y pas
de clé superflue qui se crée dans la table.

As-tu regardé le script de creation de table généré et comparé avec le tien.

Citation:

Mais en spécifiant les champs uniques dans les tables cela ne devrait pas normalement causer ce genre
de problème.

En quoi est-ce un problème ? Ces colonnes sont uniques, ce sont donc des clés fonctionnelles.

J'insiste tout de même sur la PK, ce n'est pas une invention inutile!
Cordialement
Soazig
Cordialement

24/12/2019, 14h33
escartefigue

Par contre, pour ce qui concerne la PK, évitez les colonnes de type (n)char ou pire (n)varchar peu propice aux performances et dont le contenu, le plus souvent fonctionnel, est par nature instable.
Un attribut technique de type integer et attribué par le SGBD est ce qu'il y a de mieux comme PK : stable, concis et performant :)

Citation:
Envoyé par soazig
Bonjour,

Il te suffit de nommer tes contraintes, comme cela ce sera plus clair. Une idée de script je n'ai pas pu tester.
Code:

1 2 3 4 5 6 7 8 9 10 11 CREATE TABLE tblUsers ( UserId NVARCHAR(20) constraint UQ_tblUsersUserID UNIQUE NOT NULL, UserName NVARCHAR(50) constraint UQ_tblUsersUserName UNIQUE NOT NULL, LoginName NVARCHAR(15) constraint UQ_tblUsersLoginName UNIQUE NOT NULL, UserPassword NVARCHAR(15) NOT NULL, UserStatut NVARCHAR(20) NOT NULL, UserRegistDate DATETIME, UserImage IMAGE, ); GO
As-tu regardé le script de creation de table généré et comparé avec le tien.
En quoi est-ce un problème ? Ces colonnes sont uniques, ce sont donc des clés fonctionnelles.

J'insiste tout de même sur la PK, ce n'est pas une invention inutile!
Cordialement
Soazig
Cordialement
Bonsoir.

Merci pour ces explications, c'est bien claire pour mois et cela fonctionne.

Code:

CONSTRAINT NomContrainte UNIQUE

est une contrainte pour SqlServer ce qui est tout à fait logique.
J'ai crée la table en nommant le contrainte

Code:

CONSTRAINT NomContrainte UNIQUE

comme indiqué.

Cordialement.

25/12/2019, 13h17
escartefigue

Et toujours pas de PK de préférence portée par un attribut technique ?

Citation:

Envoyé par escartefigue

Et toujours pas de PK de préférence portée par un attribut technique ?

Salut !

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
--Create Table Users
CREATE TABLE tblUsers
	(
		UserId NVARCHAR(20) NOT NULL,
		UserName NVARCHAR(50) CONSTRAINT UqUsername UNIQUE NOT NULL,
		LoginName NVARCHAR(15) CONSTRAINT UqLoginName UNIQUE NOT NULL,
		UserPassword NVARCHAR(15) NOT NULL,
		FkUserStatut INT NOT NULL,
		UserRegistDate DATETIME,
		UserImage IMAGE,
	);
GO
	ALTER TABLE tblUsers ADD CONSTRAINT PkUserId PRIMARY KEY CLUSTERED(UserId)
	ALTER TABLE tblUsers ADD CONSTRAINT FkStatutId FOREIGN KEY(FkUserStatut) REFERENCES tblStatuts(StatutId) ON UPDATE CASCADE ON DELETE CASCADE

J'ai simplement choisir de définir les contraintes de cette façon.

Cordialement;

26/12/2019, 08h08
escartefigue

Donc, vous avez bien défini une PK, mais celle-ci est de type NVARCHAR, c'est un très mauvais choix pour une PK !
26/12/2019, 10h34
TSAFACK-M

Citation:

Envoyé par escartefigue

Donc, vous avez bien défini une PK, mais celle-ci est de type NVARCHAR, c'est un très mauvais choix pour une PK !

Bonjour.

Merci pour votre observation, il est tout à fait optimal de définir une PK de type INT et définir le Code Utilisateur à part. En fait ma PK a été définie en tant que NVARCHAR parce qu'il représente le code utilisateur qui n'est pas forcément numérique.

Salutations;