Donderdag, 9 juli 2009
Serie blogposts over databases en zaken die daarbij horen
Trackbacks
Trackback-URI voor dit artikel
Geen Trackbacks
Reacties
Geeft reacties weer als
(Lineair | Samengevoegd)
Goed idee!
Wat mij wel heel handig lijkt eigenlijk is hoe je een database goed kan optimaliseren.
Lijkt me leuk als zoiets er zou komen!
Wat mij wel heel handig lijkt eigenlijk is hoe je een database goed kan optimaliseren.
Lijkt me leuk als zoiets er zou komen!
Mijn mening ken je ongeveer wel al ;)
- Sowieso een aantal van die typische beginnersfoutjes de grond indrukken (die we allemaal nog maken of ooit hebben gemaakt, zoals INT(50))
- SP's, triggers, views, domains, schemas, ...
- Iets over FK's kan misschien ook handig zijn voor enkelen onder ons
- Altijd handig: welk datatype gebruiken we nu voor wat? Daar kan je die domains al goed bij betrekken ;)
Eigenlijk zo ongeveer over alles wat met een database te maken heeft ;)
- Sowieso een aantal van die typische beginnersfoutjes de grond indrukken (die we allemaal nog maken of ooit hebben gemaakt, zoals INT(50))
- SP's, triggers, views, domains, schemas, ...
- Iets over FK's kan misschien ook handig zijn voor enkelen onder ons
- Altijd handig: welk datatype gebruiken we nu voor wat? Daar kan je die domains al goed bij betrekken ;)
Eigenlijk zo ongeveer over alles wat met een database te maken heeft ;)
Goh, ik dacht dat ik toch nog wel IETS wist van SQL.
Kom er nu achter dat dat NIET zo is :)
Dat van die padding wist ik ook niet, ik dacht altijd dat je maximaal zo veel tekens op kunt slaan dan. Maar in INT(1) kun je dus ook getallen gooien groter dan 9...
Kom er nu achter dat dat NIET zo is :)
Dat van die padding wist ik ook niet, ik dacht altijd dat je maximaal zo veel tekens op kunt slaan dan. Maar in INT(1) kun je dus ook getallen gooien groter dan 9...
Ah, je kent sowieso IETS van SQL, namelijk hoe je (zo formuleert Ben het) een databank als kladblad kunt gebruiken ;) Wat velden samengegooid zonder echte onderlinge relaties opgeschreven op een paar velletjes papier.
Wacht maar tot je ontdekt wat je allemaal in de database KAN doen... Maar alles op zijn tijd :p
Wacht maar tot je ontdekt wat je allemaal in de database KAN doen... Maar alles op zijn tijd :p
Ja wat ik gewoon graag zou willen weten is hoe je kan berekenen wat het grootste getal is van een INT(30) ofzo...
Al de rest beheers ik goed genoeg om een degelijk database te maken. Enkel de bovengrens heb ik nooit gesnapt :)
Of is hier een simpele uitleg voor die mij gewoon ontgaat? :$ :$
Al de rest beheers ik goed genoeg om een degelijk database te maken. Enkel de bovengrens heb ik nooit gesnapt :)
Of is hier een simpele uitleg voor die mij gewoon ontgaat? :$ :$
Oké, dit geintje help ik dus meteen de wereld uit:
INT(30) heeft exact dezelfde limieten als INT(1). Alleen de padding en dus bandbreedtegebruik verschilt. MySQL is ook de enige die dit soort achterlijke dingen doet. Een echte database heeft dit soort rariteiten niet.
INT(30) heeft exact dezelfde limieten als INT(1). Alleen de padding en dus bandbreedtegebruik verschilt. MySQL is ook de enige die dit soort achterlijke dingen doet. Een echte database heeft dit soort rariteiten niet.
Aah bedankt, en wat bedoel je met padding? :)
Eigenlijk is die simpeler dan jij zou denken...
Met INT(20) geef jij aan dat je wil dat de database altijd minstens 20 tekens returned. Hoe vaak zie je echter een userid met 20 tekens? Stel je de userid 1 voor. De database zal dan 19 spaties teruggeven, en 1 1.
[ (19 spaties)]1
In PHP merk je hier niks van, maar ondertussen verspil jij wel kostbare bandbreedte en resources!
Dus, vanaf heden, iedereen: gebruikt INT(1) :P
Met INT(20) geef jij aan dat je wil dat de database altijd minstens 20 tekens returned. Hoe vaak zie je echter een userid met 20 tekens? Stel je de userid 1 voor. De database zal dan 19 spaties teruggeven, en 1 1.
[ (19 spaties)]1
In PHP merk je hier niks van, maar ondertussen verspil jij wel kostbare bandbreedte en resources!
Dus, vanaf heden, iedereen: gebruikt INT(1) :P
Het is heel goed dat ook jij het licht hebt gezien ;)
Aaah erg bedankt, nu snap ik het beter.
Nog een laatste vraagje, bestaat er ook ergens een tabel van wat de max. is van alle soorten, bv tinyint enzo? :)
Dat zou ook wel erg handig zijn :$
Nog een laatste vraagje, bestaat er ook ergens een tabel van wat de max. is van alle soorten, bv tinyint enzo? :)
Dat zou ook wel erg handig zijn :$
Het lijkt me bij deze handig om van start te gaan met de juiste opzet van een database, volledig met FK constraints en bijhorende datatypen.
Vertrouwde jullie int(1) verhaal nu even niet 1,2,3 dus heb even besloten om te testen. Ik dacht altijd dat de value stond voor het aantal karakters.
Bij int(1) kun je getallen toevoegen tot 2147483648 (bij mij teminste). Echt totaal nooit geweten! Zie er al naar uit naar optimalisatie tips:P
Misschien is het handig om een blog te schrijven over andere databases dan MySQL. Omdat de meesten toch niet verder kijken dan hun neus lang is (zoals mij)
Bij int(1) kun je getallen toevoegen tot 2147483648 (bij mij teminste). Echt totaal nooit geweten! Zie er al naar uit naar optimalisatie tips:P
Misschien is het handig om een blog te schrijven over andere databases dan MySQL. Omdat de meesten toch niet verder kijken dan hun neus lang is (zoals mij)
Ik zal het je nog sterker vertellen: ik ga MySQL zoveel mogelijk proberen te ontwijken in mijn posts, vooral omdat ik het niet als database beschouw.
Ik zal het meeste gaan baseren op PostgreSQL, de meest uitgebreide opensource database.
Ik zal het meeste gaan baseren op PostgreSQL, de meest uitgebreide opensource database.
Ik zou graag willen weten welk DBMS (DataBase Management System) het 'beste' voor mij geschikt is. Nu gebruikt iedereen bijvoorbeeld PHPMyAdmin, maar ik heb sinds 6 maanden geleden SQLBuddy ontdekt. Ik snap echt niet waarom iedereen dat gebruikt, aangezien dit vele malen fijner werkt.
Verder ben ik ook benieuwd waarom je dan PostgreSQL moet gebruiken... Ik ben met MySQL tevreden genoeg :P (maar ik weet ook niet beter).
En graag zou ik ook de wat geavanceerdere kant willen leren kennen. Bij de dingen die Wouter opsomt (SP's, triggers enz.) krijg ik namelijk een hartaanval.
Verder ben ik ook benieuwd waarom je dan PostgreSQL moet gebruiken... Ik ben met MySQL tevreden genoeg :P (maar ik weet ook niet beter).
En graag zou ik ook de wat geavanceerdere kant willen leren kennen. Bij de dingen die Wouter opsomt (SP's, triggers enz.) krijg ik namelijk een hartaanval.
Ik zeg niet dat je het niet moet gebruiken, ik zeg alleen dat ik het niet wil gebruiken. Het is voor mij een database die teveel beperkingen kent op het gebied van consistentie, functionaliteit en vooral op het punt van de SQL standaard is er nog veel mis.
MySQL is alleen goed te gebruiken wanneer de config ook goed is, en dat is maar in bedroevend weinig gevallen ook echt goed.
Denk alleen al aan de standaard foute GROUP BY die wordt gebruikt om bvb een laatste forumbericht op te halen:
SELECT id, MAX(tijd), subject ......
GROUP BY id
Fout, maar niemand die het wil zien.
MySQL is alleen goed te gebruiken wanneer de config ook goed is, en dat is maar in bedroevend weinig gevallen ook echt goed.
Denk alleen al aan de standaard foute GROUP BY die wordt gebruikt om bvb een laatste forumbericht op te halen:
SELECT id, MAX(tijd), subject ......
GROUP BY id
Fout, maar niemand die het wil zien.
Wat dacht je van SELECT * FROM table ORDER BY id LIMIT 1? Of mag ik er niet vanuit gaan dat de laatste post altijd het hoogste id heeft?
Je mag er natuurlijk niet vanuit gaan dat het laatste record het hoogste id heeft. Het id is normaal gesproken opvolgend, maar zegt niets over volgorde. Het gaat hier ook niet over de MAX of wat dan ook, maar het feit dat die hele query ongeldig is en een foutmelding hoort te geven.
Kun je ook uitleggen waarom het fout is en een fout zou geven?
Let me try... ;)
Een voorbeeldje: je verkoopt een aantal laptops en je hebt de volgende tabel (slechte normalisatie, ik weet het, maar daar gaat het niet om):
id - merk - model - prijs
1 - Acer - Aspire 3810T - 599,00
2 - Toshiba - Sattelite L300-26L - 499,00
3 - Acer - Aspire 5738G - 699,00
4 - Acer - Aspire 5935G - 999,00
5 - Sony - VGN-Z41WD - 2499,00
Nu vraag je je af welke laptop van welk merk het duurste is, met andere woorden, we groeperen:
SELECT merk FROM laptops GROUP BY merk
id - merk - model - prijs
1 - Acer - Aspire 3810T - 599,00
3 - Acer - Aspire 5738G - 699,00
4 - Acer - Aspire 5935G - 999,00
2 - Toshiba - Sattelite L300-26L - 499,00
5 - Sony - VGN-Z41WD - 2499,00
We wilden de prijs van de duurste laptop, dus hier gaan we:
SELECT merk, MAX(prijs) FROM laptops GROUP BY merk
merk - MAX(prijs)
Acer - 999,00
Toshiba - 499,00
Sony - 2499,00
Merk op dat deze query nog altijd perfect geldig is!
Stel nu dat ik je vraag welk de duurste laptop van elk merk is. Welke query zou ik dan gebruiken? Jullie zouden waarschijnlijk zoiets schrijven (let op, fout voorbeeld):
SELECT merk, MAX(prijs), model FROM laptops GROUP BY merk
MySQL zal dan dit antwoorden (hoewel ik eerlijk moet zijn, het antwoord zal niet eens altijd hetzelfde zijn want het hangt af van de recordset):
merk - MAX(prijs)
Acer - 999,00 - Aspire 3810GT
Toshiba - 499,00 - Sattelite L300-26L
Sony - 2499,00 - VGN-Z41WD
Merk op dat deze gegevens dus gewoon incorrect zijn. De Aspire 3810GT kost immers geen 999,00 euro! Als model neemt MySQL gewoon de eerste record dat zich in de recordset bevind. Deze is zelfs niet altijd hetzelfde! Ik hoop dat iedereen inziet dat dat gewoon belachelijk is, dat MySQL dit beter zou afstraffen met een dikke foutmelding in de plaats van ons wiskundig onmogelijke resultaten te geven.
De regel is eigenlijk dat je nooit een veld mag selecteren dat zich niet in de GROUP BY clausule bevind OF dat geen Aggregate functie is (MAX, AVG, COUNT, SUM, ...)
Met een goede MySQL configuratie kan je dit trouwens vermijden. Helaas is dit slechts zelden het geval. Eventueel kan je bij het aanmaken van de databaseconnectie de volgende query doen:
SET sql_mode = 'TRADITIONAL,ONLY_FULL_GROUP_BY'
Een voorbeeldje: je verkoopt een aantal laptops en je hebt de volgende tabel (slechte normalisatie, ik weet het, maar daar gaat het niet om):
id - merk - model - prijs
1 - Acer - Aspire 3810T - 599,00
2 - Toshiba - Sattelite L300-26L - 499,00
3 - Acer - Aspire 5738G - 699,00
4 - Acer - Aspire 5935G - 999,00
5 - Sony - VGN-Z41WD - 2499,00
Nu vraag je je af welke laptop van welk merk het duurste is, met andere woorden, we groeperen:
SELECT merk FROM laptops GROUP BY merk
id - merk - model - prijs
1 - Acer - Aspire 3810T - 599,00
3 - Acer - Aspire 5738G - 699,00
4 - Acer - Aspire 5935G - 999,00
2 - Toshiba - Sattelite L300-26L - 499,00
5 - Sony - VGN-Z41WD - 2499,00
We wilden de prijs van de duurste laptop, dus hier gaan we:
SELECT merk, MAX(prijs) FROM laptops GROUP BY merk
merk - MAX(prijs)
Acer - 999,00
Toshiba - 499,00
Sony - 2499,00
Merk op dat deze query nog altijd perfect geldig is!
Stel nu dat ik je vraag welk de duurste laptop van elk merk is. Welke query zou ik dan gebruiken? Jullie zouden waarschijnlijk zoiets schrijven (let op, fout voorbeeld):
SELECT merk, MAX(prijs), model FROM laptops GROUP BY merk
MySQL zal dan dit antwoorden (hoewel ik eerlijk moet zijn, het antwoord zal niet eens altijd hetzelfde zijn want het hangt af van de recordset):
merk - MAX(prijs)
Acer - 999,00 - Aspire 3810GT
Toshiba - 499,00 - Sattelite L300-26L
Sony - 2499,00 - VGN-Z41WD
Merk op dat deze gegevens dus gewoon incorrect zijn. De Aspire 3810GT kost immers geen 999,00 euro! Als model neemt MySQL gewoon de eerste record dat zich in de recordset bevind. Deze is zelfs niet altijd hetzelfde! Ik hoop dat iedereen inziet dat dat gewoon belachelijk is, dat MySQL dit beter zou afstraffen met een dikke foutmelding in de plaats van ons wiskundig onmogelijke resultaten te geven.
De regel is eigenlijk dat je nooit een veld mag selecteren dat zich niet in de GROUP BY clausule bevind OF dat geen Aggregate functie is (MAX, AVG, COUNT, SUM, ...)
Met een goede MySQL configuratie kan je dit trouwens vermijden. Helaas is dit slechts zelden het geval. Eventueel kan je bij het aanmaken van de databaseconnectie de volgende query doen:
SET sql_mode = 'TRADITIONAL,ONLY_FULL_GROUP_BY'
Ja, dat gaat inderdaad niet goed, ook wel een beetje onlogisch om te denken dat het wel goed zou moeten gaan als je even redeneert. Thx voor het voorbeeld :)
Overigens nog een aanvulling:
"De regel is eigenlijk dat je nooit een veld mag selecteren dat zich niet in de GROUP BY clausule bevind OF dat geen Aggregate functie is (MAX, AVG, COUNT, SUM, ...)"
Daar mag ook bij vermeld worden dat je de velden in je ORDER BY ook moet meenemen in de GROUP.
"De regel is eigenlijk dat je nooit een veld mag selecteren dat zich niet in de GROUP BY clausule bevind OF dat geen Aggregate functie is (MAX, AVG, COUNT, SUM, ...)"
Daar mag ook bij vermeld worden dat je de velden in je ORDER BY ook moet meenemen in de GROUP.
Inderdaad, precies zoals Wouter zegt.
PostgreSQL levert hier een mooie foutmelding in de vorm van
'ERROR: column "kolomnaam" must appear in the GROUP BY clause or be used in an aggregate function'
PostgreSQL levert hier een mooie foutmelding in de vorm van
'ERROR: column "kolomnaam" must appear in the GROUP BY clause or be used in an aggregate function'
Als die SQL mode geset is geeft MySQL overigens ook een mooie, keiharde fout ;) Die van pgsql is wel een pakje duidelijker maar kom :p
Overigens, iedereen schrijft al eens een foute query met een GROUP BY, ik ook, en ik durf wedden Ben ook. Wij zien dan echter ineens een foutmelding en lossen het dan maar snel ff anders op. Als je die fout niet ziet daarentegen, dan weet je niet eens dat je fout bezig bent...
Overigens, iedereen schrijft al eens een foute query met een GROUP BY, ik ook, en ik durf wedden Ben ook. Wij zien dan echter ineens een foutmelding en lossen het dan maar snel ff anders op. Als je die fout niet ziet daarentegen, dan weet je niet eens dat je fout bezig bent...
Allicht maak ik die fout ook wel eens, maar niet heel vaak meer. Maar het is inderdaad heel belangrijk dat de foutmelding ook daadwerkelijk verschijnt.
Kalender
|
Mei '13 | |||||
| Ma | Di | Wo | Do | Vr | Za | Zo |
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 | ||
Weblogbeheer
Statistieken
Meest recente artikel: 31-07-2009 11:29
13 artikelen geschreven
146 gegeven reacties