DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
* Poging twee, nu ontopic gaarne. In dit topic kun je problemen met queries of algemene vragen over (My)SQL kwijt, gericht op beginners. Discussies over verschillende soorten script/database/opmaak/whatever-talen zijn niet gewenst. *
MySQL.com
MySQL documentatie
SQL quiz
Webmonkey PHP/MySQL tutorial
PHPMyAdmin
Devshed
PostgreSQL
PHP MySQL commando's
Fok!topics:
[PHP] voor dummies
[PHP] voor dummies - Deel 2
[PHP] voor dummies - Deel 3
PHP, C++ en MySQL voor DIG-users.
MySQL -topics in DIG
Handige linkjes:quote:The MySQL database server is the world's most popular open source database. Over five million installations use MySQL to power high-volume Web sites and other critical business systems — including industry-leaders like The Associated Press, Google, NASA, Sabre Holdings and Suzuki.
MySQL is an attractive alternative to higher-cost, more complex database technology. Its award-winning speed, scalability and reliability make it the right choice for corporate IT departments, Web developers and packaged software vendors.
MySQL.com
MySQL documentatie
SQL quiz
Webmonkey PHP/MySQL tutorial
PHPMyAdmin
Devshed
PostgreSQL
PHP MySQL commando's
Fok!topics:
[PHP] voor dummies
[PHP] voor dummies - Deel 2
[PHP] voor dummies - Deel 3
PHP, C++ en MySQL voor DIG-users.
MySQL -topics in DIG
Check je favoriete p2p software voor wat boeken in PDF formaat. Ik ken toevallig een paar daagjes geleden me wat gaan verdiepen in SQL en deze PDF-jes komen goed van pas.
ken=benquote:Op dinsdag 14 december 2004 00:05 schreef smvs het volgende:
Check je favoriete p2p software voor wat boeken in PDF formaat. Ik ken toevallig een paar daagjes geleden me wat gaan verdiepen in SQL en deze PDF-jes komen goed van pas.
(ik kan niet editen want ik heb niet de rechten om mijn eigen bericht te editen blijkbaar)
Ik ben bezig met een systeem om mijn luistergedrag online op te slaan in een database. Het werkt al prima en nu ben ik bezig met een site waar nog veel meer mensen dit kunnen gebruiken, á la Audioscrobbler, maar dan uitgebreider.
Als er meer mensen hier aan mee gaan doen wil ik een andere databaseopmaak doen. Ik heb het nu zo:
Zoals te zien is, zitten alle waarden in 2 tabellen. Dit geeft echter best onoverzichtelijke queries, vooral als ze iets uitgebreider zijn. Ook wordt deze tabel erg groot als er meerdere users hieraan mee gaan doen. Ik heb nu per maand al ongeveer 400 nieuwe rijen. Ik had als plan om de nieuwe versie op zo'n manier te doen:
Ook al zijn de tabellen per stuk veel en veel kleiner, - en bevatten ze minder strings per rij -, nu moet ik af en toe wel queries doen die over maximaal 7 tabellen tegelijk gaan. Mijn vraag is dus, heb ik hier snelheidswinst mee als ik heel veel rijen heb, of is het juist trager omdat er meer tabellen zijn?
Als er meer mensen hier aan mee gaan doen wil ik een andere databaseopmaak doen. Ik heb het nu zo:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | mp3 --- id[int(8)] - auto-increment, primary timestamp[varchar(15)] artiest[varchar(100)] titel[varchar(100)] album[varchar(100)] jaar[varchar(4)] lengte[varchar(10)] genre[varchar(25)] genre_id[int(8)] qual[varchar(10)] rate[int(5)] mod[int(1)] tel[int(8)] Genre ----- genre_id[int(4)] - auto_increment, primary genre_naam[varchar(20)] |
Zoals te zien is, zitten alle waarden in 2 tabellen. Dit geeft echter best onoverzichtelijke queries, vooral als ze iets uitgebreider zijn. Ook wordt deze tabel erg groot als er meerdere users hieraan mee gaan doen. Ik heb nu per maand al ongeveer 400 nieuwe rijen. Ik had als plan om de nieuwe versie op zo'n manier te doen:
| 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 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 | Genre ----- genre_id[int(4)] - auto_increment, primary genre_naam[varchar(20)] Artiest ------- artiest_id[int(8)] - auto_increment, primary artiest_naam[varchar(70)] artiest_genre_id[int(4)] Album ----- album_id[int(8)] - auto_increment, primary album_naam[varchar(100)] album_artiest_id[int(8)] album_jaar[varchar(4)] album_freedb_id[varchar(15)] Nummer ------ nummer_id[int(12)] - auto_increment, primary nummer_naam[varchar(100)] nummer_artiest_id[int(8)] nummer_album_id[int(8)] Ratings ------- rating_id[int(16)] - auto_increment, primary rating_nummer_id[int(12)] rating_cijfer[int(4)] rating_user_id[int(8)] Hits ---- hits_id[int(20)] - auto_increment, primary hits_nummer_id[int(12)] hits_timestamp(int(12)] hits_user_id[int(12)] Crosslinks ---------- cross_id[int(8)] - auto_increment, primary cross_type[int(4)] cross_id[int(16)] cross_newid[int(16)] Crosslinks_fuzzy ---------------- crossfuzz_id[int(8)] - auto_increment, primary crossfuzz_type[int(4)] crossfuzz_orig[varchar(100)] - case insensitive, evt. met regexp crossfuzz_new[varchar(100)] |
Ook al zijn de tabellen per stuk veel en veel kleiner, - en bevatten ze minder strings per rij -, nu moet ik af en toe wel queries doen die over maximaal 7 tabellen tegelijk gaan. Mijn vraag is dus, heb ik hier snelheidswinst mee als ik heel veel rijen heb, of is het juist trager omdat er meer tabellen zijn?
daar zijn hele mooie topics oferquote:Op woensdag 15 december 2004 15:20 schreef RicXDesign het volgende:
tvp - krijg dat f*%îng php en sql maar niet in mn kop
Kost het meer rekenkracht om een hele tabel op te halen ipv een LIMIT toe te kennen? Voor zover ik weet wordt de hele tabel sowieso doorgezocht, toch?
[ Bericht 3% gewijzigd door Heliospan op 23-12-2004 16:17:23 ]
[ Bericht 3% gewijzigd door Heliospan op 23-12-2004 16:17:23 ]
ik denk dat een limit sneller is omdat hij maar een bepaald aantal regels pakt en niet een hele table hoeft te pakken..quote:Op donderdag 23 december 2004 16:10 schreef Heliospan het volgende:
Kost het meer rekenkracht om een hele tabel op te halen ipv een LIMIT toe te kennen? Voor zover ik weet wordt de hele tabel toch doorgezocht, toch?
klopt.. een koekiequote:Op woensdag 15 december 2004 15:15 schreef VeerMans het volgende:
iedereen vind sql blijkbaar een eitje
Ik had er even bij moeten vertellen dat ik wel wil sorteren op een bepaalde kolom.quote:Op donderdag 23 december 2004 16:14 schreef mschol het volgende:
[..]
ik denk dat een limit sneller is omdat hij maar een bepaald aantal regels pakt en niet een hele table hoeft te pakken..
'SELECT * FROM tabel ORDER BY datum' - bijvoorbeeld.
Als ik dit doe wordt de hele tabel eerst gesorteerd op een kolom. Als ik een LIMIT toevoeg, wordt hierna de gevraagde aantal regels teruggestuurd.
Als je een limit doet, dan pakt hij bijvoorbeeld id 1 t/m 30, de rest kijkt 'ie niet eens meer naar.quote:Op donderdag 23 december 2004 16:10 schreef Heliospan het volgende:
Kost het meer rekenkracht om een hele tabel op te halen ipv een LIMIT toe te kennen? Voor zover ik weet wordt de hele tabel sowieso doorgezocht, toch?
Zoals jij het zegt zouden de rijen met de eerste 30 primary keys geselecteerd worden en gesorteerd worden. Echter, de hele tabel wordt geselecteerd en de eerste 30 zoekresultaten worden teruggegeven. Of ik begrijp je verkeerdquote:Op donderdag 23 december 2004 16:20 schreef _Denker het volgende:
[..]
Als je een limit doet, dan pakt hij bijvoorbeeld id 1 t/m 30, de rest kijkt 'ie niet eens meer naar.
momentje volgend jaar krijg je je antwoordquote:Op donderdag 23 december 2004 16:26 schreef Heliospan het volgende:
[..]
Ah, een expert Dan mag je deze vraag ook even beantwoorden
heb het druk...
Even een LEFT JOIN probleem/kwestie/vraag.
Ik wil bij een gegeven userid, opvragen welke referrers die heeft, maar tegelijkertijd voor elk van die referrers het aantal (sub)referers.
Uitgaande van een tabel als onderstaande tabel tbl_members
Dan zou een query als onderstaande toch moeten voldoen?
Dit zou als resultaat moeten hebben
Enkel, ik krijg gewoon (3,0) (4,0) en (9,0). Dat schiet dus niet op.
Maar volgens mij maak ik een klassieke denkfout.
Elke input is behulpzaam at this stage.
-r-
Ik wil bij een gegeven userid, opvragen welke referrers die heeft, maar tegelijkertijd voor elk van die referrers het aantal (sub)referers.
Uitgaande van een tabel als onderstaande tabel tbl_members
| 1 2 3 4 5 6 7 8 9 10 | user_id user_ref 1 NULL 2 NULL 3 1 4 1 5 3 6 4 7 3 8 3 9 1 |
Dan zou een query als onderstaande toch moeten voldoen?
| 1 2 3 4 5 6 7 8 9 10 11 12 13 | SELECT mem_1.user_id count(mem_2.user_id) as user_refs FROM `tbl_members` as `mem_1` LEFT JOIN `tbl_members` as `mem_2` ON mem_2.user_ref = mem_1.user_id WHERE mem_1.user_ref = 1 GROUP BY mem_1.user_id |
Dit zou als resultaat moeten hebben
| 1 2 3 4 | mem_1.user_id user_refs 3 2 4 1 9 0 |
Enkel, ik krijg gewoon (3,0) (4,0) en (9,0). Dat schiet dus niet op.
Maar volgens mij maak ik een klassieke denkfout.
Elke input is behulpzaam at this stage.
-r-
Ik lees vaak dingen over JOIN, LEFT JOIN en INNER JOIN. Maar, wanneer heb je die nou nodig? Ik gebruik meestal
En dat werkt ook prima?
| 1 | SELECT a.*, b.cel, b.cel2 FROM tabel1 a, tabel2 b |
En dat werkt ook prima?
goeie topic
Ooiie oooo, Waar zijn die bananen, Kom uit die bananen boom !!, Kom uit die bananen boom !!
Als ik het even snel in een Access databaseje frot dan krijg ik bijna het resultaat wat jij verwacht. Alleen Bij 3 krijg ik 3 refs i.p.v. 2 (zoals jij schrijft). Volgens mij moet het inderdaad 3 zijn.quote:Op donderdag 23 december 2004 20:07 schreef Roönaän het volgende:
Even een LEFT JOIN probleem/kwestie/vraag.
.....
Elke input is behulpzaam at this stage.
-r-
Het enige wat me verder opvalt is dat er geen , staat tussen de 2 selectievelden. (Dit zal wel een typo zijn bij het overzetten naar fok).
Als je een left join gebruikt wat ook moet, dan ben ik gewent om het als volgt op te schrijven
| 1 2 3 4 5 6 | FROM `tbl_members` as `mem_1` LEFT JOIN `tbl_members` as `mem_2` ON mem_1.user_id = mem_2.user_ref |
let op het subtiele verschil in de volgorde van de velden.
Hopelijk heb je er iets aan.
Sport is de belangrijkste bijzaak in het leven.
Ik neem aan dat je dan in de WHERE-Clause iets over de relatie tussen tabel1 en tabel2 zegt.quote:Op woensdag 29 december 2004 05:56 schreef Heliospan het volgende:
Ik lees vaak dingen over JOIN, LEFT JOIN en INNER JOIN. Maar, wanneer heb je die nou nodig? Ik gebruik meestal
[ code verwijderd ]
En dat werkt ook prima?
Anders krijg je waarschijnlijk teveel records.
Sport is de belangrijkste bijzaak in het leven.
|
|
