[PHP/MySQL] Queries samenvoegen en limit.

[Verwijderd]

Ik heb een zoekfunctie die zoekt in twee tabellen. Postcodes en Bedrijven. De input is een postcode van 4 cijfers en daar worden 3 queries mee uitgevoerd.

Dus bijvoorbeeld: 1020 = Amsterdam = Noord Holland.

1. Geef alle bedrijven die exact aan de postcode voldoen.
2. Geef alle bedrijven die niet exact aan de postcode voldoen, maar wel in dezelfde plaats vallen.
3. Geef alle bedrijven die niet exact aan de postcode voldoen, ook niet in dezelfde plaats, maar wel in de provincie.

Wat ik wil?
Ik wil eigenlijk de drie zoekresultaten samenvoegen en dan weer uitlezen in volgorde als hierboven.
Dus eerst 1. laten zien, dan 2 en dan drie. Dit moet gebeuren in pagina's met 10 resultaten.
Als ik ze kan samenvoegen dan kan ik gewoon de LIMIT en OFFSET gebruiken in de Query.

Ik heb nu
Ik raak de draad kwijt, maar ik heb nu drie queries die met limit en offset werken. Aan de hand
van het pagina-nummer worden de limits en offsets geregeld, maar dat is een heel gedoe en ik
heb het idee dat het makkelijker zou moeten kunnen.

Nu doe ik dus bijvoorbeeld:
num_rows van query1 = 5, dus nog 5 over voor query2 als limit.
num_rows van query2 = 2, dus nog 3 over voor query3 als limit.
maar dan moet ik ook nog rekening houden met de paginering.

Ik heb een beetje kennis van JOINS en van Arrays, maar ik vraag me af of dat kan,
want ik wil de resultaten op een aparte manier sorteren, en niet op naam of datum.

Kan iemand mij op weg helpen, als het wel met JOINS of Arrays zou moeten, dan
hoor ik dat graag, want loop al een tijd te puzzelen :-)

[MueR]

Waar hoort mijn topic?

WEB > PRG

[RobIII]

Zonder query (of beter, het schema van de tabellen in kwestie) kunnen we natuurlijk niets.
De enige hulp die ik je nu kan bieden: Hoe werken joins?

[WouZz]

Ik zou eens gaan kijken naar unions

[T-MOB]

Als ik het goed begrijp voer je de drie queries uit op dezelfde tabel, maar met verschillende criteria. Dat kun je natuurlijk combineren met behulp van een "OR". Vervolgens hoef je alleen maar te sorteren op diezelfde criteria om ze in de gewenste volgorde te krijgen. In pseudo-SQL:

SQL:

SELECT FROM
    bedrijven
WHERE
    {A} OR {B} OR {C}
ORDER BY
    {A} DESC, {B} DESC, {C} DESC 

[flashin]

Nee een OR of 2 in je where is een snelle efficiente oplossing!

[ Voor 17% gewijzigd door flashin op 17-12-2009 11:31 ]

[T-MOB]

flashin schreef op donderdag 17 december 2009 @ 11:29:
Nee een OR of 2 in je where is een snelle efficiente oplossing!

Als je de data nodig hebt dan heb je ze nodig, toch? Als er op drie criteria gechecked moet worden dan kun je dat met drie queries doen (lekker efficient) om maar geen "OR" in je query te stoppen, maar uiteindelijk moeten toch alle criteria gechecked worden. Maar goed, ik heb nog nooit van performance-problemen door het gebruik van OR in een WHERE clause gehoord. Ik ben dus erg benieuwd naar meer info over dit probleem (en natuurlijk jouw snellen en efficiente oplossing voor het probleem van TS).

In dit specifieke geval kun je natuurlijk wel zonder een OR wegkomen. Aangezien postcode en stad beiden in de provincie liggen kun je gewoon alles uit de provincie ophalen en dat sorteren op de overige criteria. Maar het idee van het forum is volgens mij om kennis uit te wisselen, de helemaal uitgeschreven variant is daar geschikter voor omdat ie a) generieker in te zetten is en b) makkelijker te volgen is.

[Woy]

flashin schreef op donderdag 17 december 2009 @ 11:29:
Nee een OR of 2 in je where is een snelle efficiente oplossing!

Ik zie even niet in waarom een OR inefficiënt zou moeten zijn. Het is heel erg afhankelijk van de data en de criteria waarop gefilterd moet worden.

Over het algemeen zal een RDBMS bij een AND kijken hoe hij zo snel mogelijk een record uit kan sluiten, en bij een OR hoe hij zo snel mogenlijk een record kan bevestigen als onderdeel van het result. Het is dus afhankelijk van de verdeling van de data wat de performance moet zijn.

Uiteindelijk zal je toch die criteria moeten verwerken. Aangezien er een relatie tussen de criteria zit die het RDBMS niet kan weten kun je dat inderdaad optimaliseren door gewoon alle records die in de provincie vallen te nemen, en dan te sorteren op de criteria ( Zoals T-MOB voorstelt ).

Echter is het IMHO een beetje gek om te claimen dat een OR niet snel zou zijn.