Data uitlezen database
Ik zou graag willen weten hoe ik tabellen kan combineren en het uitlezen hiervan.
In mijn database zitten de tabellen posts en users
Tabel posts heeft kolommen id, user, post en datum.
voorbeeld: 22, 45, Hier is mijn post, 2019-11-10
Tabel users heeft kolommen id, name en email.
Voorbeeld 45, jan, [email protected]
Code (php)
De output is dan 45.
Als ik nu de gekoppelde naam wil hebben uit users hoe kan ik dat als resultaat krijgen?
https://www.w3schools.com/sql/sql_join.asp
Een INNER JOIN zal je er wel bij helpen.
Gewijzigd op 13/11/2019 00:50:16 door - Ariën -
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
Ik hoop voor jou dat je dat ook in je ontwerp hebt meegenomen, anders is de kans groot dat op den duur je queries steeds trager worden wanneer deze tabellen groeien.
Volgens mij ga je pas een database optimaliseren als je een probleem hebt. Niet omdat je denkt een probleem te gaan verwachten. Als je een probleem hebt, dan pas ga je aan indexen denken. Dan nog zal je moeten weten wat er onderwater gebeurd en dat doe je door een EXPLAIN te zetten in je query. Dan nog, moet je eerst kijken waar dat die query blijft hangen. Dus zomaar lukraak roepen in dit geval om het op orderdate lijkt me dat geen goed plan.
Een datum kan aangepast worden met een update of insert dus zou het niet logisch zijn om dan op de datum een index te zetten. Waar moet je het dan wel doen? Dat kan je pas zeggen als je de uitkomst weet van je explain. ;)
Zoals ik het zie optimaliseer je je tabellen op grond van de manier waarop je de data gebruikt. De database staat per slot van rekening in dienst van de applicatie. Blijkbaar is orderdate een argument voor sorteren/filteren in ten minste één query. Dus het kan zeker geen kwaad om daar een index op te zetten. Nu merk je nog weinig van performance issues, maar als beide tabellen beginnen te groeien kan dit snel achteruit hollen. En je wéét dat dit gaat gebeuren, dus waarom zou je dit dan niet meteen regelen? Dit kost geen enkele moeite.
Ik denk niet dat het "piepsysteem" *1 (in dit geval) een valide ontwikkelstrategie is, tenzij je wellicht inkomsten uit onderhoud genereert ofzo. Maar je zou dit ook kunnen beschouwen als bochten afsnijden in het ontwerp, die je later keihard weer op je bord terugkrijgt, mogelijk als je al met andere dingen bezig bent... Ain't nobody got time for that.
Dus tenzij je geen reet geeft om de technical debt die je hier genereert (je collega's zullen je hier ook dankbaar voor zijn) zou ik dit toch anders aanpakken...
Databases vormen vaak het fundament van een applicatie. Hier mag dus best veel tijd en denkwerk ingestoken worden. Als het fundament al krakkemikkig is dan hoef je van de rest ook niet veel te verwachten.
*1 piepsysteem = pas ingrijpen op het moment dat er problemen geconstateerd worden
Gewijzigd op 13/11/2019 19:35:24 door Thomas van den Heuvel
Ik zeg nergens dat je je systeem niet vanaf 0 heel slim in moet richten.
Dat je eerst een test maakt met big dummy data lijkt me een zeer voor de hand liggend, althans zo heb ik het altijd wel gedaan. Dan pas kan je testen of alles naar behoren werkt alvorens je live gaat met je applicatie.
Als je dan tegen dit soort problemen aanloopt, dan kan je met explain die query's slimmer maken met indexen.
Dus ik denk dat wij het zelfde bedoelen alleen het anders benaderen/uitleggen.