Discussion :

[new_wave]

Bonjour,

J'ai crée une table LOUER, qui est une table de jointure, avec ce script suivant

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
 
 
CREATE TABLE LOUER (id_mbre NVARCHAR(10),
id_exempl_dvd NVARCHAR(10),
id_dvd_orig NVARCHAR(10), 
date_loc DATE NOT NULL, 
date_fin_loc DATE 
CONSTRAINT LOUER_date_fin_nn NOT NULL ,
date_lim_loc DATE
CONSTRAINT LOUER_date_lim_nn NOT NULL,
 
CONSTRAINT LOUER_id_mem_ex_dvd_pk PRIMARY KEY (id_mbre, id_exempl_dvd, id_dvd_orig),
 
CONSTRAINT LOUER_id_mem_fk FOREIGN KEY(id_mbre) REFERENCES 
MEMBRE(id_mbre),
 
CONSTRAINT LOUER_id_ex_dvd_orig_fk 
FOREIGN KEY(id_exempl_dvd, id_dvd_orig)REFERENCES  EXEMPLAIRE_DVD(id_exempl_dvd, id_dvd_orig));

J'ai bien créé, auparavant, toutes les tables auxquelles il est fait référence dans ce script.

Je me suis rendue compte, que le champ date_loc a été oublié au niveau de la clé primaire.

J'ai donc tout d'abord supprimé toutes les contraintes de clé étrangères, comme ceci

Code :

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

1
2
3
4
 
ALTER TABLE LOUER DROP LOUER_id_mem_fk ;
ALTER TABLE LOUER DROP  LOUER_id_ex_dvd_orig_fk;
1b-ALTER TABLE LOUER DROP LOUER_id_mem_ex_dvd_pk ;

Puis ai recrée une contrainte de clé primaire correcte ainsi

Code :

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

1
2
 
ALTER TABLE LOUER ADD CONSTRAINT LOUER_id_mem_ex_dvd_date_pk PRIMARY KEY(id_mbre, id_exempl_dvd, id_dvd_orig, date_loc);

Puis j'ai recrée les contraintes de clés étrangères sur les 4 champs

Code :

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

1
2
3
4
5
 
ALTER TABLE LOUER ADD CONSTRAINT LOUER_id_mem_fk FOREIGN KEY(id_mbre)REFERENCES MEMBRE(id_mbre);
 
ALTER TABLE LOUER ADD CONSTRAINT LOUER_id_ex_dvd_orig_fk FOREIGN KEY(id_exempl_dvd, id_dvd_orig) REFERENCES EXEMPLAIRE_DVD(id_exempl_dvd, id_dvd_orig);
ALTER TABLE LOUER ADD CONSTRAINT LOUER_date_loc_fk  FOREIGN KEY(date_loc)REFERENCES DATE_LOCATION(date_loc);

si la création des contraintes de clés étrangères fonctionne correctement pour ces deux contraintes LOUER_id_ex_dvd_orig_fk et LOUER_date_loc_fk, en revanche, pour la création de la clé primaire LOUER_id_mem_fk, je reçois le message suivant

Msg*547, Niveau*16, État*0, Ligne*1
L'instruction ALTER TABLE est en conflit avec la contrainte FOREIGN KEY "LOUER_id_mem_fk". Le conflit s'est produit dans la base de données "GESTION_DVD_2", table "dbo.MEMBRE", column 'id_mbre'.

Il se trouve que j'ai bien supprimé la contrainte de clé étrangère lorsque j'ai lancé la requête

Code :

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

1
2
 
ALTER TABLE LOUER DROP LOUER_id_mem_fk ;

En pièce jointe, on voit bien que la contrainte id_mem_fk n'existe pas pour la table LOUER.
pouvez-vous m'expliquer pourquoi je ne parviens pas à créer à nouveau cette contrainte de clé étrangère.

Je vous en remercie beaucoup.

new_wave

[rudib]

Bonjour,

à part plusieurs remarques que j'ai envie de faire sur la structure (id_mbre NVARCHAR(10) ????), que donne ceci ?

Code :

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

1
2
3
4
SELECT l.*
FROM LOUER l
LEFT JOIN MEMBRE m ON l.id_mbre = m.id_mbre
WHERE m.id_mbre IS NULL

[new_wave]

Bonjour,
J'ai finalement trouvé ce qui ne convient pas .
Il s'agit du fait que j'ai inséré dans la table LOUER un enregistrement avec une clé primaire id_mbre qui n'existe pas dans la table MEMBRE

Tu n'es pas d'accord sur le type de données.

Utiliser le type int avec un auto increment te semble préférable?

J'ai quand même appris que si l'on ne fait pas de calcul avec un champ, il est préférable de choisir le type varchar ou nvarchar.

Qu'en penses tu?
Quelles sont les autres remarques?

Cordialement.
new_wave

[rudib]

Il y a toute un série de problèmes liés au choix du type de données, je te suggère de lire un peu sur le sujet, par exemple dans les articles de sqlpro. Mais ici, notamment, tu choisis un NVARCHAR, qui stocke de l'UNICODE, donc 2 octets par caractères, et tu construis une clé primaire clustered par-dessus, donc tu augmentes artificiellement le stockage de ta table, tu gaspilles de l'espace en RAM pour le cache et tu diminues les performances de la base de données parce que tu augmentes les I/O.

[new_wave]

Merci à toi de ta réponse,

Je vais donc modifier cela en choisissant le type int avec un auto increment sur les champs clés primaires.
Je vais également lire les articles de sql pro là dessus.

Bien cordialement.

new_wave

[new_wave]

Bonjour,

J'ai lu quelques articles sur le types de données CHAR et VARCHAR.
Je m'en suis "inspirée" pour les types de données de ma base de données .

J'ai cependant lu des avis contradictoires.
Connais tu un article "scientifique" sur ces deux types de données et le choix clair qui s'impose en fonction de telle ou telle situation.

Si c'est le cas, je te remercie de bien vouloir me communiquer le lien vers ces articles .

Bien cordialement.

new_wave

[rudib]

Je ne connais rien de scientifique, mais la science n'a qu'un rapport distant avec le schmilblick dans ce cas.

Par exemple : si tu veux acheter une voiture pour te déplacer exclusivement à Paris (mauvais idée en soi je l'admets), vas-tu opter pour un 4x4 ?

C'est donc plus une question de bon sens : le CHAR remplit l'espace libre par des espaces. Donc tu augmentes artificiellement le stockage de ta table, tu gaspilles de l'espace en RAM pour le cache et tu diminues les performances de la base de données parce que tu augmentes les I/O.

CHAR(5) pour un code postal = taille fixe et connue à l'avance => OK
CHAR(50) pour un nom => pas OK.

Si tu lis des textes sur l'intérêt du CHAR pour accélérer la récupération des données dans la page, dis-toi qu'ils datent du temps où les processeurs n'avaient pas les mêmes capacités de traitement qu'aujourd'hui. Le gain algorithmique du CHAR n'a aujourd'hui plus aucun intérêt par rapport au gain en I/O du VARCHAR.