MYSQL::JOIN op tabellen met dezelfde structuur
Even een simpel voorbeeld, error, uitleg structuur in deze/dit topic:
Ik probeer het volgende:
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
SQL-query:
SELECT *
FROM donations, temp_donations
WHERE login = 'ufig13'
OR person = 'ufig13'
ORDER BY time DESC
LIMIT 0 , 30
SELECT *
FROM donations, temp_donations
WHERE login = 'ufig13'
OR person = 'ufig13'
ORDER BY time DESC
LIMIT 0 , 30
En krijg de volgende error terug:
Code (php)
1
2
3
2
3
MySQL retourneerde:
#1052 - Column: 'login' in where clause is ambiguous
#1052 - Column: 'login' in where clause is ambiguous
Wat ik probeer:
Het selecteren van meerdere rijen uit 2 tabellen die PRECIES dezelfde structuur hebben. Deze tweede tabel(temp_donations) bestaat voor backups van geld-transacties voor gebruikers die dood zijn. Bij het sterven worden dus ALLE rijen van die gebruiker die dood gaat van donations naar temp_donations verplaatst. Na één week worden de rijen uit temp_donations verwijdert, wat ons een behoorlijk tijd geeft om te kijken of deze person terecht dood gaat.
Verder:
Ik begrijp deze error helemaal, maar kan geen oplossing verzinnen.
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
SELECT *
FROM donations as a, temp_donations as b
WHERE a.login = 'ufig13'
OR a.person = 'ufig13' OR b.login = 'ufig13'
OR b.person = 'ufig13'
ORDER BY a.time, b.time DESC
LIMIT 0 , 30
FROM donations as a, temp_donations as b
WHERE a.login = 'ufig13'
OR a.person = 'ufig13' OR b.login = 'ufig13'
OR b.person = 'ufig13'
ORDER BY a.time, b.time DESC
LIMIT 0 , 30
Dit werkt ook niet helemaal(komen rijen tevoorschijn die hier niks mee te maken hebben).
Oplossing die mogelijk kan zijn:
Gegevens uit beide tabellen halen en in een array zetten, en die dan weer sorteren op de time. Dat lijkt me ook niet al te makkelijk/snel gaan, en het lijkt me veel makkelijker als MySQL dit kan oplossen.
Bij voorbaat dank voor jullie hulp!
~Martijn
Edit:
Typo's, BB-codes.
Gewijzigd op 01/01/1970 01:00:00 door Zero Dead
Quote:
Zoals? Met de query die je als laatste geeft lijkt me vrij weinig mis...Dit werkt ook niet helemaal(komen rijen tevoorschijn die hier niks mee te maken hebben).
Wat ik me wel afvraag, waarom heb je dit in twee tabellen staan? Je kunt toch net zo goed in de ene tabel een veld creëren waarin je aangeeft of iemand dood is en eventueel een veld met datum van overlijden?
Ik neem aan dat een record nog niet uit de 1e tabel is verwijderd, als die naar de andere gegaan is.
Dus als die "ufig13" dood is, dan staat die nog in de gewone en in de temp tabel? En je wilt uit beide tabellen de records hebben, waarbij de user "ufig13" is?
Als wat ik hierboven noem voor je klopt, probeer onderstaande dan eens. En anders gaarne even toelichten wat er precies met een record gebeurt uit de gewone tabel, als die naar de temptabel wordt verplaatst.
(verwijderd of niet, of een bepaald veld op 1 of 0 gezet :))
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
SELECT
*
FROM
ea_donations as a
LEFT JOIN
temp_ea_donations as b
ON
a.login = b.login
WHERE
a.login = 'ufig13'
ORDER BY
a.time, b.time DESC
LIMIT 0 , 30
*
FROM
ea_donations as a
LEFT JOIN
temp_ea_donations as b
ON
a.login = b.login
WHERE
a.login = 'ufig13'
ORDER BY
a.time, b.time DESC
LIMIT 0 , 30
Blanche schreef op 08.11.2006 16:56:
Wat ik me wel afvraag, waarom heb je dit in twee tabellen staan? Je kunt toch net zo goed in de ene tabel een veld creëren waarin je aangeeft of iemand dood is en eventueel een veld met datum van overlijden?
Quote:
Zoals? Met de query die je als laatste geeft lijkt me vrij weinig mis...Dit werkt ook niet helemaal(komen rijen tevoorschijn die hier niks mee te maken hebben).
Wat ik me wel afvraag, waarom heb je dit in twee tabellen staan? Je kunt toch net zo goed in de ene tabel een veld creëren waarin je aangeeft of iemand dood is en eventueel een veld met datum van overlijden?
Bij > 30.000 rijen is het toch handig om zo'n 2500 rijen minder in de tabel te hebben, dit is namelijk wat sneller.
Is het geen UNION wat jij zoekt? Met een UNION-query kun je 2 resultsets aan elkaar knopen:
SELECT veld1, veld2 FROM tabel_1 UNION SELECT veld1, veld2 FROM tabel_2
Quote:
Ik neem aan dat een record nog niet uit de 1e tabel is verwijderd, als die naar de andere gegaan is.
Het werkt als volgt:
Gebruiker1 stuurt geld naar Gebruiker2, dit word natuurlijk opgeslagen in een log.
Als Gebruiker1 sterft word er gekeken naar zijn geld-logs, dat in een while gegooit wordt en dan word 1 voor 1 gekeken of de andere gebruiker(van de transactie) nog leeft, om misverstanden te voorkomen.
Is dit niet het geval, dan word de rij gekopieërt naar temp_ea_donations(backup) en word hij verwijdert uit ea_donations(niet meer nodig, scheelt ruimte en snelheid).
Dan word er een cron eens per dag uitgevoert om de rijen die langer dan 1 week in temp_ea_donations staan te verwijderen. Scheelt nog meer ruimte.
Nu wil ik dus alle rijen uit de database halen van deze gebruiker. Dus ook de verplaatste.
Quote:
Ik krijg het idee dat je bezig bent met micro-optimalisatie. Bij > 30.000 rijen is het toch handig om zo'n 2500 rijen minder in de tabel te hebben, dit is namelijk wat sneller.
Een database is gemaakt om miljoenen, honderden miljoenen tot zelfs miljarden records te bevatten en jij gaat je druk maken om 2500 records? Het lijkt mij allemaal nogal zinloos.
Ga eerst eens het hele systeem benchmarken (dus alle queries en alle php-code apart klokken) om te zien waar nu daadwerkelijk tijdswinst is te behalen.
Wanneer blijkt dat er in de queries een hoop tijdswinst is te behalen (minimaal 70% tijdswinst t.o.v. de php-code waar dan 30% winst zou zitten), ga je dan eens verdiepen in het gebruik van de juiste indexen in de queries. Helaas kun je in MySQL per query slechts 1 index gebruiken, maar dan nog valt daar een hoop (factor 1000 is mogelijk) mee te winnen.
Zonder benchmark is het zinloos om zo maar wat te gaan proberen en je datamodel om zeep helpen om te optimaliseren lijkt mij nooit een goed plan.
De PHP-code heb ik al behoorlijk geoptimaliseerd(bijv. met dingen als mysql_fetch_row, mysql_free_result etc.) en nu zijn de MySQL-tabellen en queries aan de beurt.
Indexen worden overal gebruikt, en waar mogelijk ook primary keys. Maar dan is het nog wel behoorlijk wat sneller als er minder rijen in één tabel staan. Logish, want als bijv. een mens 1 ding tussen 10 verschillende dingen moet zoeken is hij sneller klaar dan wanneer hij hetzelfde tussen 100 dingen moet zoeken. Waarom zou dit dan niet met een database zorgen dat het veel sneller gaat?
En door optimalisatie heb ik ook de load behoorlijk omlaag weten te krijgen(van de webserver & de databaseserver), wat ook weer zorgt voor versnelling(eigenlijk zorgt een hoge laod juist voor 'versloming'). Omdat sommige queries per 10 seconden 50 keer worden opgeroepen, vraagt dit toch al behoorlijk wat load van beide servers. Als hij dan tussen 2x zoveel rijen iets moet gaan zoeken springt de load zo omhoog, wat weer zorgt dat alles veel slomer gaat. En ik verwacht/hoop binnekort een groei van gebruikers te krijgen en dan is het makkelijk als de meeste optimalisatie al is gebeurt.
@ Remco, dit was inderdaad wat ik zocht maar ik had hier nog nooit van gehoord dus dan word het moeilijker om er op te komen ;) Hartstikke bedankt!