Discussion :

[dafpp]

Bonjour, je voudrai simplement savoir si déclarer sa donnée en tant que clef étrangère était vraiment utile?

bah oui:

Code :

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

1
2
3
select *
from a, b
where a.id = b.id;

marche très bien.

Quel est le réelle intérêt de déclarer une donnée en clef étrangère ou j'ai mal compris qqchose ?

[SQLpro]

Aucun, c'est totalement cosmétique. Si on met des clefs étrangères c'est pour le fun !
D'ailleurs beaucoup milite pour les retirer puisque ça sert à rien !!!































et si vous lisiez un peu avant de poser des questions ????

A +

[skuatamad]

Caustique comme réponse, mais ça se comprend
Aller dafpp un début de réponse dans :
Intégrité référentielle (FOREIGN KEY / REFERENCES)

Sinon fait aussi des recherche sur CASCADE, un mot clé très important et extrèmement pratique des contraintes d'intégrités référentielles.

[Maljuna Kris]

Bonjour, je voudrai simplement savoir si déclarer sa donnée en tant que clé étrangère était vraiment utile?

bah oui:

Code :

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

1
2
3
select *
from a, b
where a.id = b.id;

marche très bien.

Quel est le réelle intérêt de déclarer une donnée en clé étrangère ou j'ai mal compris qqchose ?

Saluton,
Dura lex sed lex, serait-elle la devise de ce bon SQLpro.

En cette fin de soirée je trouvais pourtant la candeur de ce post....rafraîchissante.

[dafpp]

je sais très bien ce que c'est une clef étrangère (désolé pour les clé et pas clef, on voit de tout sur le net, donc après on sait plus l’orthographe - même si ça paraissait plus logique pour clef... bref).

je voulais savoir ce qu'apportait vraiment d'indiquer foreign key, puisque un lien reste un lien, et si qu'on sait que a.id c'est la même chose que b.id, on a juste à sélectionner donc tout ce qui est égale. Je pensais par là en posant ma question s'il n'y avait pas quelque chose d'automatique, mais c'est pas le cas, donc résolu !
merci

[Maljuna Kris]

Au passage, évitons de raviver la guerre des étoiles et, depuis 1982 (bientôt 20 ans ma doué!) la syntaxe normalisée pour les jointures est plutôt

Code :

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

1
2
3
SELECT les_noms_de_colonne_qui_vont_bien_plutôt_qu_étoile
FROM a
INNER JOIN b USING (id)

ou

Code :

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

1
2
3
4
SELECT les_noms_de_colonne_qui_vont_bien_plutôt_qu_étoile
FROM a
INNER JOIN b 
ON a.id=b.id

[dafpp]

merci, j'en tiendrai bien compte

INNER JOIN ? je connaissais pas, je vais revoir tout ça.
C'est plus rapide que WHERE ? ça permet de joindre 2 tables par rapport à leur clef étrangère directement ?

edit: en effet, ,je viens de lire le cours de cyberzoide, qui est très bien expliqué, et qui indique que pour faire une jointure, il y a plus rapide:
- ce que tu as dis juste au dessus.

Merci à tous

[CinePhil]

Ce n'est, en principe, ni plus rapide ni plus lent mais c'est surtout plus lisbile et évite des erreurs dans les requêtes car avec l'ancienne syntaxe il est très facile d'oublier une condition de jointure. Je ne compte plus le nombre de requêtes en erreur postées ici, écrites avec l'ancienne syntaxe, que j'ai résolues simplement en récrivant les jointures correctement. Dans 90% des cas, il manquait une condition de jointure !

Pour tout savoir sur les jointures : c'est encore chez SQLPro.

[dafpp]

d'accord merci