Aller au menu - Aller au contenu

[SQL] Sélection multi-tables

Pour accéder à cette section
Connectez-vous !
connexion_rpx
Page 1 
Pseudo Commentaire
Page 1 
Hors ligne Xavinou # Posté le 30/06/2007 à 11:28:19
Mieux vaut tard que trop tard
Avatar
Groupe : Anciens

Ville : Strasbourg
Pays : France métropolitaine
Études : IUT Strasbourg-Sud

 Salut,

c'est un bon tuto, mais ya une erreur de cardinalité : dans la première partie, la où il y a le schema de tes 2 entité et de l'assiociation, la cardianlité coté auteur n'est pas la bonne : c'est plutôt : 0,n que 1,n. D'ailleur, plus bas, tu le dit toi meme !

Xav57

PS : 17
Hors ligne Snipy11 # Posté le 30/06/2007 à 11:58:54
Avatar
close

Études : ESIEE Engineering Paris

 J'allais faire la même remarque que ci dessus.

Le tuto est certe un peu simpliste en ce qui concerne les cardinalités mais il a le mérite d'être clair
Cherche Codeur et Designer pour jeu en ligne de gestion d'une equipe de Basket
 
Hors ligne Awaken # Posté le 01/07/2007 à 16:21:39
Avatar

Avis : Mitigé

C'est quoi la différence entre ta technique et le fait d'utiliser un LEFT JOIN ?
The greatest trick the Devil ever pulled was convincing the world he didn't exist.
 
Hors ligne anonyme # Posté le 01/07/2007 à 17:10:28

Sa méthode est beaucoup plus lourde qu'une jointure.
Avec sa méthode on fait d'abord le produit des tables (ça équivaut à un CROSS JOIN) et ensuite on élimine les lignes qu'on ne veut pas avec le WHERE.
Avec une jointure appropriée, on ne lira que les lignes qui nous intéresse, on évitera ainsi de charger des trucs inutiles et on gagnera du temps.
Bref, dans le cas que tu énonces, une jointure est bien plus adaptée que ta sélection multi-table.

Faudrait aussi préciser que ta clé étrangère n'est pas indispensable, et surtout que si on essaie de faire ça sur une table MyISAM ça va échouer vu qu'elles ne gèrent tout simplement pas les clé étrangères.
Hors ligne jordan # Posté le 02/07/2007 à 12:50:54
Développeur professionnel
Avatar
Flux RSS
close

Ville : Couternon
Pays : France métropolitaine
Études : Université de Dijon

 Hmm, c'est intéressant de parler des contraintes d'intégrité entre les tables en proposant l'utilisation des ALTER TABLE `table` ADD CONSTRAINT mais pour que ça fonctionne, les tables DOIVENT être en InnoDB.

Si par défaut leur PhpMyAdmin est configuré comme ça, pas de problème, mais c'est tellement rare...

Heureusement lors de la création de la table, on peut le forcer :
Code : SQL
CREATE TABLE IF NOT EXISTS `table` (
  `champs` TYPE,
  PRIMARY KEY (`champs`)
) ENGINE=InnoDB
Hors ligne BoZ # Posté le 09/07/2007 à 19:48:28
M'Voyez!
Avatar

 Il est vrai que MySQl est rarement configuré en InnoDB :'( .
Mais il n'y a pas que MySQL :-° .
--
Image utilisateur
 
Hors ligne Shepard # Posté le 16/07/2007 à 22:41:38
SQL Beginner ...
Avatar
Groupe : Anciens

Ville : Mouscron
Pays : Belgique
Études : Université de Mons-Hainaut

 En effet il n'a jamais dit qu'il utilisait MySQL ^^

Par contre je ne peux qu'appuyer Haku: ta méthode est beaucoup plus lourde qu'une jointure normalisée ( en fait la virgule remplace CROSS JOIN dans ce cas ci, et ce quel que soit le SGBDR ( R pour relationnelles, et tes données le sont puisque tu mets 2 tables en relation ^^ )

De plus tu n'expliques pas vraiment le principe des sous-requêtes: où peut-on les utiliser ? Quel est leur impact sur la rapidité de la requête ?

Ce serait pas mal aussi de préciser l'utilité des FOREIGN KEY, et donc de parler de l'intégrité référentielle ... ( et éventuellement de l'optimisation faite par le SGBDR sur les jointures entre les deux tables concernées, même si ce n'est pas le but des FOREIGN KEYs ... )

Voilà, à peauffiner mais ton tuto a le mérite d'aborder un sujet auquel peu de gens ont osé se confronter :)
Hors ligne alexises # Posté le 29/03/2008 à 17:16:44
merci m@téo pour la v3
Avatar

Études : IUT Paris

 je trouve ce tuto est peut clair dans la description des requétes au niveau de la 2e méthode : je n'ai pas compris le principe.
je met comme note 5
Image utilisateur
 
Hors ligne anonyme # Posté le 19/04/2008 à 15:00:48

salut

juste pour te dire que le AS est un formalisme Microsoft (Access notamment) et n'est pas dans la norme SQL

pour faire un alias, on fait ainsi

Code : SQL
1
SELECT NoAuteur no


comme lorsque l'on joint des tables, c'est le même principe ;)

EDIT : ah et aussi

Code : SQL
1
2
3
4
5
SELECT * 
FROM news AS n, auteurs AS a 
WHERE n.id_auteur = a.id_auteur 
AND nom="DUPONT" 
AND prenom="Marchel"


c'est préférable de faire ainsi :

Code : SQL
1
2
3
SELECT *
FROM news N INNER JOIN auteurs A ON N.id_auteur = A.id_auteur
WHERE nom = 'DUPONT' AND prenom = 'Marchel';


les jointures se font en INNER JOIN ou (left|right)OUTER JOIN
les valeurs sont entre simples quotes ' '

voila, j'espère avoir été clair :)

bon tuto en tout cas (et désolé, l'habitude au boulot ;) )
Hors ligne djlixfe # Posté le 19/04/2008 à 17:14:47

Citation :
juste pour te dire que le AS est un formalisme Microsoft (Access notamment) et n'est pas dans la norme SQL

Je suis parfaitement désolé de te le dire, mais j'ai l'impression que tu n'as pas lu la norme sql.
AS est bel et bien utilisé pour renommer les attributs dans la norme.
AS est implémenté dans presque tous les SGBD; ce n'est donc pas un formalisme microsoft.

2eme point
Code : SQL
1
2
3
4
5
SELECT * 
FROM news AS n, auteurs AS a 
WHERE n.id_auteur = a.id_auteur 
AND nom="DUPONT" 
AND prenom="Marchel"


Il vaut mieux utiliser les opérateurs de jointures normalisés comme l'a dit @Loup Bleu. à nom="DUPONT": il doit avoir des apostrophes et non des guillemets
Hors ligne mrjay42 # Posté le 20/04/2008 à 23:15:57
We gotta take the power back
Avatar
Flux RSS
close

N'y a t'il pas une erreur dans le questionnaire (3eme question) :
Code : SQL
1
SELECT email FROM news AS n, auteur AS a WHERE n.id=3 AND n.id_auteur=a.id_auteur

Est suggéré comme bonne réponse.

Est ce que cela ne devrait pas plutot être :
Code : SQL
1
SELECT email FROM news AS n, auteur AS a WHERE n.id=3 AND n.id=a.id_auteur


Quel dommage que les jointures soient faites avec des where!
Moi qui comptais me mettre aux "INNER JOIN", pour faire plaisir à `Haku ^^
Mon 'blog-bloc note'
Win the yes need the no to win against the no
Un peu d'humour
Optimisations en SQL
Oh My God !

L'homme qui doit seul vanter ses mérites sait que personne ne le fera à sa place
Ne confondez pas le coût et la valeur des choses
 
Connecté SpaceFox # Posté le 29/05/2008 à 00:15:54
Utilise ton cerveau !
Avatar
Validateurs
Flux RSS
close

Études : UTT

 Un bon point, avoir abordé cette notion de jointure : on trouve encore plein de sites persos (ou pas) avec des tables super mal conçues, parce que les gens ne savent pas faire ça.

Mais deux mauvais points :
Un très gros, déjà dit plusieurs fois ci-dessus, tant qu'à faire des jointures, autant les faire proprement. Pour la grande majorité des sites persos, on verra pas la différence ; mais si un type veut utiliser ça sur un vrai projet, il va avoir des requêtes super lentes...
Le deuxième est que, tant qu'à utiliser une norme pour faire tes schémas, autant en utiliser une vraie (genre UML), plutôt que cette chose franco-française qu'est Merise...
Image utilisateur
 
Hors ligne Draeli # Posté le 29/05/2008 à 08:34:45
Avatar

 Merise qui reste la base apprise dans les BTS Informatique et qui permet de modéliser très bien tous ce qu'on veut.

(Beaucoup d'entreprises feraient bien d'embaucher des gens qui sont compétents car perso même dans des grosses boîtes les tables c'est la catastrophe ...)

Sinon pour le tuto, ca mériterait d'être appronfondi.

(question pour l'auteur, tu utiliserais pas AnalyseSI pour tes schémas ?)
Jedi PHP (Certifié Zend PHP) - Jedi MySQL (Certifié MySQL Core) - Jedi CSS
Le côté obscur de la force bientôt rejoins ai-je ! :-°
- A bove ante, ab asino retro, a stulto undique caveto -
 
Hors ligne ghuysmans99 # Posté le 29/05/2008 à 21:24:42
Avatar
Flux RSS
close

Je trouve qu'utiliser un INNER JOIN est plus facile mais bon ...
VB.NET is good ... VB6 is better :D
 
Hors ligne sicilien007 # Posté le 30/09/2010 à 16:35:26

Avis : Décevant

Rien sur les requêtes corrélées!
La technique 2 c'est une jointure (Pas ANSI) mais c'est une jointure, alors que la première remarque ... Une jointure ne serait pas une requête mais plusieurs !!!
Des tables présentées avec un MCD !!!
Donc des erreurs, des imprécisions, très léger en somme. Du merise et du SQL mal digérés !!!
1+1=3
«La théorie, c'est quand on sait tout et que rien ne fonctionne. La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi. Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !» (Albert Einstein)
 
Hors ligne wadouda # Posté le 07/12/2010 à 18:05:27

Je me tourne vers vous pour vous de mandez de l'aide. Je dois mettre en place une base de donnée pour une "Agence d'assurance".Entité/association
quelques entités:agent d'assurance, assurer,contrat,gestion de personnel,sinistre,.... j'ai besoins des autres entités et comment je les reliés avec des associations
Je n'arrive pas à mettre en place cette base de données, donc si quelqu'un pouvait m'aiguiller.
Je ne vois pas comment quels tables je peux avoir, combien, comme vous pouvez le comprendre j'ai du mal à démarrer ma méthode merise.

Merci d'avance pour les réponses.
Hors ligne mouhisoft # Posté le 17/05/2011 à 15:35:48
Avatar

Ville : Bruxelles
Pays : Belgique

 Salut tous,
Citation : ghuysmans99
Je trouve qu'utiliser un INNER JOIN est plus facile mais bon ...

Il ne faut pas dire que les jointures sont plus facile que le MCD, même avec un MCD on utilise les jointures.
Le MCD c'est un modèle qui nous permet de représenter notre BDD sous forme d'un graphe, et il existe des outils tels que DB-Main qui permettent de transformer le MCD en MLD (Modèle logique des données) ou en MPD (Modèle physique de données) c'est-à-dire il nous permet de créer des tables automatiquement a partir de l'MCD, et puis pour interroger la BDD les requêtes restent les mêmes : SELECT, UPDATE, JOIN, IN, ALL,...

A propos le tuto je trouve qu'il est pas mal, mais il manque beaucoup de choses par exemple : Dans le MCD la clé primaire doit être précédée par un dièse #, parce que un attribut(champ) qui est souligné veut dire seulement que sa valeur est unique mais on peut avoir dans la même entité(table) une clé primaire exemple : #id et un attribut(champ) unique souligné exemple matricule, au même temps.

J'ai constaté aussi que vous n'avez pas crée le MPD(la table) de votre association, vous devriez avoir 3 tables après la traduction, et c'est pour ça vos requêtes sembles un peux compliqués.
Et une dernière remarque, le fait que vous n'avez pas mentionné que dans le MCD une table devient une entité et un champ devient un atrribut, et que l'association n'est un pas une relation comme vous l'avez indiqué, dans le MCD elle reste une association.

Voila désolé pour les remarques et je vous souhaite bon courage pour amélioré votre tutoriel.

Salut.
Pour accéder à cette section
Connectez-vous !
connexion_rpx