MYSQL::JOIN op tabellen met dezelfde structuur

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Java Developer / Overheid / Complexiteit

Functieomschrijving Wil jij als Java Developer een bijdrage leveren aan een veiliger Nederland en je als Java Developer bezig houden met zeer complexe bedrijfskritische applicaties? Lees dan snel verder! Doorontwikkelen bedrijfskritische applicaties; Aanpassingen maken in de bestaande applicatie; Vertalen van jouw visie op continuous integration en continuous delivery; Debuggen van de applicatie; In gesprek gaan met eindgebruikers om verbetervoorstellen op te halen. Functie-eisen Minimaal HBO-werk en denkniveau; Minimaal 5 jaar werkervaring als Java Developer; Je bent minimaal OCP-Java SE 6 gercertificeerd; Je hebt kennis van Webservices en Continuous Integration; Je bent analytisch sterk en zowel klant- als resultaatgericht. Bedrijfsomschrijving Binnen

Bekijk vacature »

Senior DevOps-ontwikkelaar eIDAS

Functie­omschrijving Burgers en bedrijven veilig en betrouwbaar digitaal toegang geven tot diensten en producten van het ministerie van Economische Zaken en Klimaat. Als senior DevOps-ontwikkelaar bouw je daar letterlijk aan mee. En dat doe je bij DICTU: een van de grootste en meest vooruitstrevende ICT-dienstverleners van de Rijksoverheid. Jij werkt mee aan de doorontwikkeling van eIDAS, dat staat voor Electronic IDentification Authentication and trust Services. Deze koppeling maakt de grensoverschrijdende authenticatie op overheidswebsites binnen de Europese Unie mogelijk. Het ministerie van Economische Zaken en Klimaat heeft één moderne toegangspoort voor zijn diensten en inspecties. Enkele daarvan zijn dankzij eIDAS inmiddels

Bekijk vacature »

Front-end Developer Vue.js Meewerkend voorman

Functieomschrijving Ben jij een ervaren Front-end Developer, bedreven in Vue.js en lijkt het jou gaaf om als meewerkend voorman verantwoordelijk te zijn voor de ontwikkeling van drie junior ontwikkelaars? Werk jij graag aan diverse projecten t.b.v. het vergroten van klant- en medewerkerbeleving? Lee dan snel verder! Het onderhouden, ontwikkelen en testen van front-end software van diverse klant- en medewerkersapplicaties; Het ontwikkelen van maatwerk front-end oplossingen in Vue.js en participeren in een scrumteam; Verantwoordelijk voor het begeleiden en coachen van drie junior front-end developers; Verantwoordelijk voor code-reviews en het opstellen van de juiste documentatie zoals userstories en api ontwerp; Participeren in

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

04/08/2020 19:08:36
 
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.