Deux requetes, une réponse mais avec des champs différents.

rickways · 06-01-2010 11:25:05

Bonjour,

Je viens demander à l'aide !!!

J'ai un souci pour lequel je n'ai pas vraiment d'idée de résolutions.

J'ai donc deux tables différentes contenant toutes les deux des poèmes:

- Une table poesieetpeinture (champs: id, titre, poeme, auteur, datepoeme,...)
- Une table themedumois (champs: id, titre, poeme, auteur, datedupoeme, ...)

J'aimerais afficher les 10 derniers poèmes reçus quelque soit la table de laquelle ils proviennent:
par exemple on pourrait avoir le 5 premiers poèmes viennet de poesieetpeinture, puis 3 de themedumois, puis 2 de poesieetpeinture

Pour chaque résultat, il faut que l'url de redirection vers le poème soit différente :
pour les résultats de poesieetpeinture, l'url sera plpoeme.php?id=, et pour themedumois, l'url ser tdmpoeme.php?id=

Pour le moment je suis capable de faire les deux requetes séparement et de les afficher séparément, mais impossible de les afficher dans un seul tableau.

MERCI POUR VOS CONSEILS

Eric

Maskime · 06-01-2010 11:37:39

Hello,

Je suis pas spécialiste SQL mais est ce que quelque chose comme ça ne ferait pas l'affaire ?

    SELECT pp.id, pp.titre, pt.id, pt.titre

       FROM poesieetpeinture pp, themedumois pt

     WHERE 1=1

ORDER BY pp.datedupoeme, pt.datedupoeme DESC

       LIMIT 1,10

/me se demande vraiment si ca va marcher... :\

rickways · 06-01-2010 13:39:28

Au niveau de la requête je pense avoir à peu près trouvé, mais le problème c'est que je n'arrive pas à différencier l'url en fonction de la provenance de la table

(SELECT id,titre,poeme,auteur,datepoeme,valid
FROM poesieetpeinture
WHERE valid=1
ORDER by datepoeme DESC
LIMIT 7)
UNION
(SELECT id,titre,poeme,auteur,datedupoeme,valid
FROM themedumois
WHERE valid=1
ORDER by datedupoeme DESC
LIMIT 7)
ORDER by datepoeme DESC

Maskime · 06-01-2010 13:58:25

Hello,

Essaye comme ça :

     ( 

        SELECT id,titre,poeme,auteur,datepoeme,valid, 'poesiepeinture' AS provenance 

          FROM poesieetpeinture

         WHERE valid=1

      ORDER BY datepoeme DESC

         LIMIT 7

     )

UNION

     (

        SELECT id,titre,poeme,auteur,datedupoeme,valid, 'themedumois' AS provenance

          FROM themedumois

         WHERE valid=1

      ORDER BY datedupoeme DESC

         LIMIT 7

     )

ORDER BY datepoeme DESC

Et après tu fais un test sur la colonne 'provenance'

Maljuna Kris · 07-01-2010 13:25:23

Saluton kaj bonan novjaron,
Je ne crois pas que MySQL supporte la clause LIMIT dans les sous-requêtes, et surtout, par rapport au poste initial, pourquoi LIMIT 7 ?

Maskime · 07-01-2010 13:41:13

Maljuna Kris a écrit :

Saluton kaj bonan novjaron,
Je ne crois pas que MySQL supporte la clause LIMIT dans les sous-requêtes, et surtout, par rapport au poste initial, pourquoi LIMIT 7 ?

Pour être franc je ne sais pas non plus et en plus en ce moment je suis sous oracle donc je peux pas tester

xTG · 07-01-2010 17:14:23

Je viens de tester et cela ne génère pas d'erreurs sous MySql.

Maljuna Kris · 07-01-2010 19:05:56

Ouais, au temps pour moi, cette restriction semble dater de versions MySQL 4...

rickways · 07-01-2010 22:49:49

Merci maskime,

cette solution marche parfaitement, avec un petit if et else if ensuite, on obtient de très bons résultats...

rickways · 07-01-2010 22:53:58

Pour ce qui est des limites à l'intérieur des requêtes, c'est que le nombre de résultats pourrait dépasser les 5000 donc elles me sont indispensables, et effectivement cela marche, pas d'erreur Sql

Maskime · 08-01-2010 14:47:25

Hello,

pour les LIMIT on faisait plus référence aux valeurs de ton LIMIT => 7 + 7 = 14 et non 10 comme tu le précise dans ton message de début.

rickways · 09-01-2010 11:52:45

Ok pour cette remarque, en fait j'ai juste changer d'avis... je suis passé à 14 résultats.

Par contre information pour ceux que ça intéresse, les résultats obtenus sont donc 7 résultats de chaque table classés par date.

Je me demande si en supprimant la clause limit au début et en l'ajoutant après à tout le tableau on obtiendrait surement les derniers 14 résultats (et non moitié, moitié)

Je testerais...

Maskime · 11-01-2010 08:47:05

Hello,

Je pense que si tu supprimes les LIMIT dans tes sous-requêtes et que tu mets un LIMIT 14 à la fin de ton UNION, tu auras les 14 derniers résultats toutes tables confondues.
MySQL ne cherchera pas à te faire un ratio 50/50.

Maljuna Kris · 11-01-2010 11:55:49

Par contre la requête sera plus lente car la limitation se fera sur la globalité de l'UNION qui devra donc être d'abord réalisée intégralement.

xTG · 11-01-2010 12:33:08

Maljuna Kris a écrit :

Par contre la requête sera plus lente car la limitation se fera sur la globalité de l'UNION qui devra donc être d'abord réalisée intégralement.

Il suffit de faire un LIMIT dans les sous-requêtes.

Si le LIMIT de l'union est de 14 alors on fait un LIMIT de 28 dans les sous-requêtes et le tour est joué.

Maljuna Kris · 11-01-2010 13:20:02

xTG a écrit :

Il suffit de faire un LIMIT dans les sous-requêtes.
Si le LIMIT de l'union est de 14 alors on fait un LIMIT de 28 dans les sous-requêtes et le tour est joué.

Bizarre ta logique, pourquoi 28 ?
14 dans chaque sous-requête me semble suffisant.

xTG · 11-01-2010 16:43:48

Ah oui il voulait un ratio 50/50... Au temps pour moi.

rickways · 11-01-2010 18:20:52

Merci pour vos propositions et votre aide.

Cela marche parfaitement.

Pour ce qui est des limit... j'ai fait plus compliqué que cela, mais c'est uniquement par rapport aux différentes sections.
Pour chacune des sections j'ai choisi des limit relatives aux nombres d'envoi par jour....

et j'ai même rajouter un deuxième union (avec une autre table), et ça marche parfaitement, j'ai compris le truc je pense....

Merci encore.

ERIC

Maskime · 14-01-2010 12:46:12

Hello,

Attention ca marche bien pour le moment parce que tu n'as pas trop d'enregistrements.
Je ne sais pas quelles sont perspectives pour l'avenir, mais UNION ramène vraiment BEAUCOUP d'enregistrement donc regarde bien si tu as besoin de tout ça.

Mais bon pour le moment ca marche comme tu veux c'est l'essentiel

rickways · 14-01-2010 17:41:06

Pour le moment je fais une recherche sur trois tables:

Une table de 1489 poèmes (Avec un limit de 10)
une autre de 3247 poèmes (Avec un limit de 20)
et une dernière de 351 poèmes.(Avec un limit de 5)
Le tout avec un limit de 15.

ça marche parfaitement (surement parce qu'il n'y a pas beaucoup d'enregistrement effectivement), néanmoins je ne saurais pas faire autrement pour le moment puisque je vous avais demandé de l'aide à ce sujet.

Espérons que cela dure....

xTG · 14-01-2010 20:24:52

Si tu fais tes limit avant l'union il n'y a pas de soucis.
Il fait actuellement une union avec 10+20+5 enregistrements.

Maljuna Kris · 15-01-2010 10:02:38

C'est à dire que ces trois tables quasi identiques, ça sent quand même 'cor'assez le défaut de conception.

rickways · 16-01-2010 02:02:41

Bonjour Kris...

Il y a en effet surement des défauts de conceptions et j'essaie de les améliorer avec le temps.
Néanmoins chaque table étaient assez différentes au départ et avec le temps elles se sont uniformisées.

Mais ces trois tables me semblent réellement devoir être séparées, puisque chaque section à ces spécificités (deux à trois colonnes différentes)

Penses tu qu'elles pourraient être regroupées en laissant des colonnes inutiles pour certains types d'envois ?

Pour être plus précis:

Table thème du mois:
- Tout est commun, sauf une colonne THEME
Table poésie et peinture
- Tout est commun sauf une colonne catégorie (différentes du principe du thème)
Table poésie d'hier:
- Tout est commun sauf une colonne SOURCE (identifiant les recueils dans lesquels on trouve le poème)

Si cela est possible pourquoi pas, serait-ce une meilleur idée.

En sachant que chaque section est différente sur le site et qu'il n'y a que sur la page d'accueil que je cherche à regrouper tous les nouveaux poèmes ?

Merci d'avance pour tes conseils...

ERIC

Maskime · 18-01-2010 13:29:41

Hello,

En fait tu prends le problème à l'envers.
Actuellement ce que tu fais c'est faire la liste des colonnes de tes différentes tables déjà existantes et tu te demande si elles sont toutes utiles.

Il faut que tu identifies les différentes entités cohabitant dans ton système.
De ce que je constate tu as une entité que tu pourrais appeler "texte", une qui serait "thème" et enfin une dernière qui serait "catégorie".

Une fois que tu les as identifiées, il faut les définir.
Pour cette partie il me faudrait que tu me dises quels sont les colonnes dans chacune des tables.

Quand tu as identifié les entités et que tu les as définies, tu peux établir les différentes relations entre les entités et de cette définition de relations tu obtiens ton modèle de BDD. Ensuite une petite touche pratique pour faire en sorte que ton modèle réponde bien à tes besoins et tu obtiens finalement un modèle de BDD qui tient la route, évolutif, maintenable et qui ne te demande pas de faire des requêtes comme tu les fais actuellement

Pour information, dans ce genre d'application, la BDD est là où se trouve une très grosse partie de l'intelligence du développement. Faire un bon modèle de BDD est essentiel pour travailler dans de bonnes conditions par la suite. Donc passer un peu de temps sur sa conception n'est pas forcément une perte de temps

PHP|Débutant :: Forums

Advertisement

#1 06-01-2010 11:25:05

Deux requetes, une réponse mais avec des champs différents.

#2 06-01-2010 11:37:39

Re : Deux requetes, une réponse mais avec des champs différents.

#3 06-01-2010 13:39:28

Re : Deux requetes, une réponse mais avec des champs différents.

#4 06-01-2010 13:58:25

Re : Deux requetes, une réponse mais avec des champs différents.

#5 07-01-2010 13:25:23

Re : Deux requetes, une réponse mais avec des champs différents.

#6 07-01-2010 13:41:13

Re : Deux requetes, une réponse mais avec des champs différents.

#7 07-01-2010 17:14:23

Re : Deux requetes, une réponse mais avec des champs différents.

#8 07-01-2010 19:05:56

Re : Deux requetes, une réponse mais avec des champs différents.

#9 07-01-2010 22:49:49

Re : Deux requetes, une réponse mais avec des champs différents.

#10 07-01-2010 22:53:58

Re : Deux requetes, une réponse mais avec des champs différents.

#11 08-01-2010 14:47:25

Re : Deux requetes, une réponse mais avec des champs différents.

#12 09-01-2010 11:52:45

Re : Deux requetes, une réponse mais avec des champs différents.

#13 11-01-2010 08:47:05

Re : Deux requetes, une réponse mais avec des champs différents.

#14 11-01-2010 11:55:49

Re : Deux requetes, une réponse mais avec des champs différents.

#15 11-01-2010 12:33:08

Re : Deux requetes, une réponse mais avec des champs différents.

#16 11-01-2010 13:20:02

Re : Deux requetes, une réponse mais avec des champs différents.

#17 11-01-2010 16:43:48

Re : Deux requetes, une réponse mais avec des champs différents.

#18 11-01-2010 18:20:52

Re : Deux requetes, une réponse mais avec des champs différents.

#19 14-01-2010 12:46:12

Re : Deux requetes, une réponse mais avec des champs différents.

#20 14-01-2010 17:41:06

Re : Deux requetes, une réponse mais avec des champs différents.

#21 14-01-2010 20:24:52

Re : Deux requetes, une réponse mais avec des champs différents.

#22 15-01-2010 10:02:38

Re : Deux requetes, une réponse mais avec des champs différents.

#23 16-01-2010 02:02:41

Re : Deux requetes, une réponse mais avec des champs différents.

#24 18-01-2010 13:29:41

Re : Deux requetes, une réponse mais avec des champs différents.

Pied de page des forums