MYSQL::JOIN op tabellen met dezelfde structuur

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

.NET Developer / Innovatieve software / Virtual Re

Functieomschrijving Als .Net developer werken aan innovatieve software waar onder andere gebruik gemaakt wordt van Virtual Reality? Bijdragen aan een organisatie waar je uitgedaagd wordt om continu verbeteringen en ontwikkelpunten te ontdekken en door te voeren? Werken in de omgeving Putten? Reageer dan nu voor meer informatie! Het pro-actief aandragen van verbeteringen voor de bestaande applicatie; Ontwikkelen van nieuwe functionaliteiten; Doorvoeren van aanpassingen en wijzigingen; Verantwoordelijk voor koppelingen met andere systemen; Op de hoogte blijven van technische ontwikkelingen. Functie-eisen Hbo werk- en denkniveau; Een afgeronde IT gerelateerde opleiding; Minimaal 1 jaar professionele ervaring als developer; Aantoonbare kennis van C#; Initiatiefrijke

Bekijk vacature »

Zero Dead

Zero Dead

08/11/2006 14:12:00
Quote Anchor link
Hoi allemaal, ik kom even niet uit een JOIN query, en google biedt ook geen hulp.

Even een simpel voorbeeld, error, uitleg structuur in deze/dit topic:

Ik probeer het volgende:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
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


En krijg de volgende error terug:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
MySQL retourneerde:  

#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)
PHP script in nieuw venster Selecteer het PHP script
1
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


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
 
PHP hulp

PHP hulp

15/11/2019 21:31:11
 
Joren de Wit

Joren de Wit

08/11/2006 16:56:00
Quote Anchor link
Quote:
Dit werkt ook niet helemaal(komen rijen tevoorschijn die hier niks mee te maken hebben).
Zoals? Met de query die je als laatste geeft lijkt me vrij weinig mis...

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?
 
Robert Deiman

Robert Deiman

08/11/2006 17:32:00
Quote Anchor link
@ZeroDead

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)
PHP script in nieuw venster Selecteer het PHP script
1
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
 
Zero Dead

Zero Dead

08/11/2006 18:15:00
Quote Anchor link
Blanche schreef op 08.11.2006 16:56:
Quote:
Dit werkt ook niet helemaal(komen rijen tevoorschijn die hier niks mee te maken hebben).
Zoals? Met de query die je als laatste geeft lijkt me vrij weinig mis...

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.
 
Remco van Arkelen

Remco van Arkelen

08/11/2006 18:25:00
Quote Anchor link
2 tabellen die precies dezelfde structuur hebben is al discutabel :)
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
 
Zero Dead

Zero Dead

08/11/2006 18:26:00
Quote Anchor link
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.
 
Frank -

Frank -

08/11/2006 18:30:00
Quote Anchor link
Quote:
Bij > 30.000 rijen is het toch handig om zo'n 2500 rijen minder in de tabel te hebben, dit is namelijk wat sneller.
Ik krijg het idee dat je bezig bent met micro-optimalisatie.

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.
 
Zero Dead

Zero Dead

09/11/2006 09:55:00
Quote Anchor link
@ Frank, dit systeem was orgineel gemaakt voor eens soort van backups van de gebruikers hun gegevens. Hiervoor werd alles gewoon verwijdert, zonder kans dat het terug gehaalt kon worden. Als ik nooit rijen uit deze tabel zou gooien word deze al snel zo groot dat het hele systeem heel sloom word.

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!
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.