[MySql] 6 tabellen aan elkaar koppelen met 1 statement

[judgem]

Gegroet,

Voor het maandelijkse e-zine (zie undersign) wat ik in elkaar geprogrammeerd heb, leek het me een leuk idee om ook elke maand op de personeelspagina (ik ben overigens Michiel B. voor de mensen die dat wat interesseert) automatisch een overzichtje te laten genereren met wie van de crew in het huidige issue 1 of meerdere artikelen hebben geschreven..

Ik gebruik hiervoor de volgende tabellen:

* lom (waarin de variabele van het huisige issuenr is opgenomen)
* crew (waarin de namen en de crew_id's zijn opgenomen)
* reviews (met o.a. een veld voor crew_id en issuenr)
* interviews (met o.a. een veld voor crew_id en issuenr)
* live_reviews (met o.a. een veld voor crew_id en issuenr)
* specials (met o.a. een veld voor crew_id en issuenr)

Wat ik dus middels een MySQL statement wil bewerkstelligen is is dat er nagegaan wordt in de tabellen reviews, interviews, live_reviews en specials (onze vaste maandelijkse rubrieken) wie van de medewerkers een artikel hebben geschreven. Met andere woorden: wiens crew_id komt er voor het huidige issue (de variabele in de tabel "lom") voor in tenminste 1 van de 4 genoemde tabellen..

Nu heb ik al een aantal opties geprobeerd (o.a. LEFT JOIN en UNION) maar die kunnen blijkbaar maar hooguit 3 tabellen aan. Het onderstaande leek me de meest logische optie maar toch levert die niet het juiste resultaat (ik krijg wederom alle medewerkers te zien):

code:

SELECT DISTINCT realname 
FROM crew WHERE EXISTS 
    (SELECT l.current_issue, i.issuenr, r.reviewer, in.interviewer, s.schrijver, li.reviewer 
     FROM reviews r, interviews in, specials s, live_reviews li, lom l
     WHERE i.issuenr = l.current_issue 
     AND li.issuenr = l.current_issue 
     AND in.issuenr = l.current_issue 
     AND r.issuenr = l.current_issue 
     AND s.issuenr = l.current_issue) 
AND crew_id NOT IN (1) 
ORDER BY realname ASC

crew_id 1 is overigens onze hoofdredacteur en die wordt bovenaan al vermeld...

Ik hoop dat iemand me wat verder kan helpen.. BVD..

[ Voor 1% gewijzigd door judgem op 16-03-2003 21:02 . Reden: query-foutje ]

[Goodielover]

Je moet het oplossen met 4 afzonderlijke subselects op ieder van de tabellen.
Nu test je wie van de crew alles heeft geschreven.

Je wilt waarschijnlijk een WHERE crew.crew_id IN (select .... UNION select ... UNION select ... UNION select ....) gebruiken

Bedenk ook dat de alias "in" voor de tabel interview een reserved word kan zijn.

Ik vind dat je tabel ontwerp ook wel wat commentaar verdient.

Als je bijdragen aan een tijdschrift hebt, zou het logischer zijn om dat dan ok zo te modelleren.

[ Voor 21% gewijzigd door Goodielover op 16-03-2003 21:30 ]

[judgem]

Goodielover schreef op 16 maart 2003 @ 21:29:
Je moet het oplossen met 4 afzonderlijke subselects op ieder van de tabellen.
Nu test je wie van de crew alles heeft geschreven.

Je wilt waarschijnlijk een WHERE crew.crew_id IN (select .... UNION select ... UNION select ... UNION select ....) gebruiken

klopt als een bus

Bedenk ook dat de alias "in" voor de tabel interview een reserved word kan zijn.

Dat is niet het geval maar toch bedankt om me er even op te wijzen..

Ik vind dat je tabel ontwerp ook wel wat commentaar verdient.
Als je bijdragen aan een tijdschrift hebt, zou het logischer zijn om dat dan ok zo te modelleren.

Zou u dat misschien wat nader willen toelichten? Het draait in principe als een tierelier alleen op dit vlak zat ik even met de handen in het lange haar...

Dank voor de info tot zover in elk geval.. Ik ga eens proberen of een stukje herschrijven wil werken.. Ik hou u allen op de hoogte

[ACM]

Wel knap, dat je een subselect query kan in mysql

Of draai je de 4.1-alpha??
Ik heb zelfs het idee dat ie de keyword exists niet eens kent, magoed

[judgem]

ACM schreef op 16 March 2003 @ 22:22:
Wel knap, dat je een subselect query kan in mysql

Of draai je de 4.1-alpha??
Ik heb zelfs het idee dat ie de keyword exists niet eens kent, magoed

precies... das dus effe de pest ervan.. Ik zat stiekem te hopen dat er hier alternatieven voor bestonden om een dergelijke query in MySQL wel uit te kunnen voeren..

Het is geen halszaak maar het zou toch wel geinig zijn als het zou lukken..

[Verwijderd]

Even een vraagje over je database ontwerp hoor: wat is het verschil tussen reviews, interviews, live_reviews en specials?
Als de kolommen voor die tabellen gelijk of vrijwel gelijk zijn, kun je misschien beter alles in één tabel zetten, en een extra kolom toevoegen, met een foreign key naar een nieuw te maken tabel `article_type` met kolommen `article_type_id` en `article_type_name`.

Dan heb je meteen een paar tabellen minder, en het lijkt mij dat het geheel dan ook beter is genormaliseerd?

[Verwijderd]

... had niet goed gelezen ...

[ Voor 91% gewijzigd door Verwijderd op 16-03-2003 22:43 ]

[judgem]

Verwijderd schreef op 16 March 2003 @ 22:41:
Even een vraagje over je database ontwerp hoor: wat is het verschil tussen reviews, interviews, live_reviews en specials?
Als de kolommen voor die tabellen gelijk of vrijwel gelijk zijn, kun je misschien beter alles in één tabel zetten, en een extra kolom toevoegen, met een foreign key naar een nieuw te maken tabel `article_type` met kolommen `article_type_id` en `article_type_name`.

Dan heb je meteen een paar tabellen minder, en het lijkt mij dat het geheel dan ook beter is genormaliseerd?

De overeenkomsten:
- allemaal het veld "auto_id"
- allemaal een schrijver (of gastschrijver)
- allemaal een issuenr
- overal een teller hoe vaak het artikel gelezen is
- allemaal wat achterliggende info als wie het gepost heeft, op welke datum en vanaf welk IP enzo
- een "staat het artikel geactiveerd"-variable (0 of 1)

Een aantal specifieke velden:
* reviews:
- titel van de CD/DVD/etc
- label waarop het is uitgebracht
- website van het label
- score voor de review
- plaatje van de hoes
- signature van de schrijver

* interviews
- persoon met wie het interview gehouden is
- plaatje van het bandlogo
- plaatje van de hoes van de laatst gemaakte plaat
- pakkende quote voor de indexpagina

* specials
- titel van het verhaal
- omschrijving voor de indexpagina

* live reviews
- fotograaf (of gastfotograaf)
- zaal waar het optreden plaatsvond
- datum wanneer het plaatsvond
- pakkende quote voor de indexpagina


Dus mijns inziens toch iets te afwijkend om er 1 grote tabel van te maken.. Zeker aangezien we momenteel *effe checken* 2148 reviews, 77 live reviews (moet nog een hoop archiefmateriaal ingevoerd worden), 208 interviews (idem als bij de live reviews) en 10 specials in de database hebben staan....

[Verwijderd]

Die aantallen zijn nou niet bepaald veel voor in een tabel.

Je zou voor de structuur ook kunnen denken aan een soort 'objecten' tabel, waarin alle gedeelde elementen staan samen met het type en het id van de bijbehorende tabel. In die bijbehorende tabellen staan dan de item-specifieke zaken

[judgem]

mja, dan zou ik alles weer om moeten gaan gooien terwijl het al ruim een half jaar als een zonnetje loopt..

Het "1 grote query"-idee laat ik maar even varen denk ik en ik ga het op een andere manier op proberen te lossen (tenzij iemand uiteraard een beter idee heeft.. )

[Olaf van der Spek]

Het kan toch best in een query in MySQL?
Gewoon voor elke type bijdrage een left join met de crew table using crew ID en dan in de where kijken met OR of minstens een van de bijdrage IDs niet NULL is.

[ACM]

Je zou nog zoiets kunnen overwegen:
artikel: artikel_id, ... (alle overeenkomsten)
review: review_id, ..., artikel_id (alle verschillen met artikel)
special: special_id, ..., artikel_id (alle verschillen met artikel)

etc
Maar echt beter dan je huidige model is het denk ik niet, hoewel het wel iets beter genormaliseerd is.

[djluc]

Wat ik zou doen is één tabel maken met de velden die nu in meerdere tabellen voorkomen, en dan een extra tabel met alle andere gegevens, de typen gegevens kun je eventueel ook nog in een andere tabel zetten.

[judgem]

OlafvdSpek schreef op 17 March 2003 @ 11:13:
Het kan toch best in een query in MySQL?
Gewoon voor elke type bijdrage een left join met de crew table using crew ID en dan in de where kijken met OR of minstens een van de bijdrage IDs niet NULL is.

hmmm.. dat valt te proberen natuurlijk.. thanks voor de tip

ACM schreef op 17 maart 2003 @ 11:57:
Je zou nog zoiets kunnen overwegen:
artikel: artikel_id, ... (alle overeenkomsten)
review: review_id, ..., artikel_id (alle verschillen met artikel)
special: special_id, ..., artikel_id (alle verschillen met artikel)

Dat is wellicht een overweging waard voor een toekomstige bouwen online zine..

[judgem]

Ik zat nu te denken aan een oplossing om eerst 4 statements te maken (de 4 artikeltabellen uitlezen), deze vervolgens naar een array weg te schrijven en daar dan weer een qury op los te laten om de namen te krijgen alleen heb ik even geen flauw idee hoe dat aan te pakken...

Iemand een suggestie?

[Goodielover]

Dan kan je beter 4 queries maken met direct de namen erin en die dan in een ontdubbelen in een array.

[judgem]

das nog niet eens zo'n slecht plan inderdaad

[judgem]

Leuk nog even mijn oude bookmarks nalopen

Maar in elk geval is het kort na de laatste post allemaal gelukt. Ik heb het op de volgende manier aangepakt:

- 4 sql queries gemaakt met schrijvers per artikeltype (wel met DISTINCT erin)
- de resultaten van deze 4 queries in lussen laten toevoegen in een array
- middels een dubbele for-loop na afloop de namen uit de array op het scherm laten tonen (al eerder getoonde namen hiermee afgevangen zodat ze er geen 2 keer in zouden staan als bijvoorbeeld iemand zowel een interview als een review geschreven had..)

Deze mag dus dicht. Eenieder bijzonder veel dank voor de hulp

[djluc]

Kun je dat ontdubbelen niet al doen door WHERE NOT IN te gebruiken in de query's na het eerste query? Dan hoef je namelijk minder gegevens uit je db te halen.

[ Voor 25% gewijzigd door djluc op 05-10-2003 12:06 ]