[mysql] database structuur

[Verwijderd]

Heej daar mensen, ik had ff wat vragen over hetgeen ik aan het maken ben...

Ik ben bezig met een systeem waar je de mogelijkheid hebt om punten te scoren voor dingen die je kan doen. Ik heb nu de volgende vraag: Hoe kan ik deze structuur het beste indelen..

Wat ik nu heb is het volgende:

tabel user:
- nick
- wachtwoord
- email
- etc

tabel usergegevens:
- nick
- voornaam
- achternaam
- etc

tabel useraccount:
- nick
- punten
- nog een paar andere dingen


De tabel user is puur en alleen voor login gegevens en dergelijken (email, wachtwoord, nickname, homepage, etc)
Waarom ik een apparte tabel usergegevens heb gemaakt is om de volgende reden, het is niet altijd zo dat als je je registreerd dat je al je persoonlijke gegevens ook moet opgeven, vandaar dus gescheiden. En dan de tabel useraccount, hierin komen de punten te staan die je scoort...

nou vraag ik me af wat ik hieraan kan verbeteren, want ik heb het idee dat het niet super effiecient is..

[thomaske]

ik zou in ieder geval de tabellen koppelen met een userID ipv met de nick.

Verder kan het geen kwaad om alles in 1 tabel te doen hoor..

[whoami]

Waarom verdeel je alles in verschillende tabellen? Ik zie er het nut niet van in.

[Verwijderd]

Op maandag 18 maart 2002 11:28 schreef whoami het volgende:
Waarom verdeel je alles in verschillende tabellen? Ik zie er het nut niet van in.

Voor een goed overzicht lijkt mij.

[Verwijderd]

Ik doe het met de nickname het koppelen omdat ik ze tegelijk na mekaar insert... anders zou ik eerst nog een query moeten doen voor last_inserted_id bijvoorbeeld...

Ik verdeel het over verschillende tables omdat bijvoorbeeld niet voor elke gebruiker de velden in de tabel usergegevens moeten worden ingevuld.. Of kan ik alles juist wel beter in 1 tabel doen en dan die velden maar open laten voor een user waar dat niet van op toepassing is??

iemand voorstellen?

[LuCarD]

Op maandag 18 maart 2002 11:26 schreef thomaske het volgende:
ik zou in ieder geval de tabellen koppelen met een userID ipv met de nick.

Hoezo wat is het voordeel hiervan? Een nick moet toch Unique zijn binnen de database?

Verder is het niet echt een probleem om alles in 1 tabel te doen hoor..

Zeker user en usergegevens mogen bij elkaar worden gezet. Aangezien ze beide hetzelfde object beschrijven. En verder een 1 op 1 relatie hebben.

Als useraccount een dat ook heeft mag deze ook worden toegevoegd aan tabel user.

[Verwijderd]

Op maandag 18 maart 2002 11:30 schreef LuCarD het volgende:

Zeker user en usergegevens mogen bij elkaar worden gezet. Aangezien ze beide hetzelfde object beschrijven. En verder een 1 op 1 relatie hebben.

Dus ook als niet altijd de velden die eerst in usergegevens stonden niet altijd worden ingevuld? dus zo ontstaan er lege gaten op sommige velden.. is dat een probleem?

[dusty]

Op maandag 18 maart 2002 11:30 schreef LuCarD het volgende:
[..]
Hoezo wat is het voordeel hiervan? Een nick moet toch Unique zijn binnen de database?
[..]

Databases zijn sneller met getallen, betekent dus dat als je tabellen gaat koppelen dat dat dus sneller gaat met getallen ipv strings.

[dusty]

Op maandag 18 maart 2002 11:34 schreef DiStance het volgende:
[..]
Dus ook als niet altijd de velden die eerst in usergegevens stonden niet altijd worden ingevuld? dus zo ontstaan er lege gaten op sommige velden.. is dat een probleem?

Nope dat is geen probleem.

Ik heb het trouwens in mijn eigen database anders gedaan en niet alles in een tabel gedaan maar in drie verschillende tabellen.

Maar dat was voornamelijk om het veel dynamischer te maken

[Verwijderd]

Op maandag 18 maart 2002 11:37 schreef dusty het volgende:

[..]

Nope dat is geen probleem.

Ik heb het trouwens in mijn eigen database anders gedaan en niet alles in een tabel gedaan maar in drie verschillende tabellen.

Maar dat was voornamelijk om het veel dynamischer te maken

Dus wat raad je me aan? Alles in 1 tabel? Ik moet wel zeggen dat bijvoorbeeld de tabel useraccount erg vaak geupdate gaat worden.. Is het dan dus niet verstandiger om die tabel bijvoorbeeld appart te houden?

[Anders]

Op maandag 18 maart 2002 11:30 schreef LuCarD het volgende:
[..]
Hoezo wat is het voordeel hiervan? Een nick moet toch Unique zijn binnen de database?

Databases zijn sneller met getallen, betekent dus dat als je tabellen gaat koppelen dat dat dus sneller gaat met getallen ipv strings.

Die snelheid is maar een marginaal argument. Belangrijker is het dat je, als je een koppeling maakt via een record-id, je maar 1 tabel hoeft langs te lopen om de nickname van iemand te wijzigen, in plaats van een hele rats aan tabellen. Kun je wel zeggen "de nicknames mogen toch niet gewijzigs worden" maar dan ga je voorbij aan het principe van normalisatie en werk je jezelf vroeg of laat de nesten in.

Ik ben nu zelf bijvoorbeeld zeer veel tijd kwijt aan het herbouwen van een beheersysteem waarin plaatjes en artikelen aan elkaar verbonden waren via de titel. Gevolg: als je de titel van een artikel wijzigt, werkt de hele koppeling met de plaatjes niet meer. Kun je de titel bij al die plaatjes ook gaan wijzigen maar dan moet je onnodig veel werk verzetten. Koppel je de plaatjes aan het id van het artikel, dan heb je wat dat betreft geen centje pijn.

Alles in 1 tabel? Ik moet wel zeggen dat bijvoorbeeld de tabel useraccount erg vaak geupdate gaat worden.. Is het dan dus niet verstandiger om die tabel bijvoorbeeld appart te houden?

user en usergegevens moet je echt samenvoegen. Het heeft geen enkel nut om die apart te houden, want de gegevens hebben immers altijd betrekking op 1 en dezelfde user. Werk je met twee tabellen, dan krijg je straks onnodig veel, en onnodig ingewikkelde queries. Hoe vaak iets geupdate moet worden doet niet terzake: je update immers alleen de kolommen die je wilt updaten. Hoeveel kolommen er verder in de tabel staan is niet van belang.

[LuCarD]

Op maandag 18 maart 2002 11:35 schreef dusty het volgende:

[..]

Databases zijn sneller met getallen, betekent dus dat als je tabellen gaat koppelen dat dat dus sneller gaat met getallen ipv strings.

Hoor ik daar een benchmark aan komen????

[Verwijderd]

Anders: Dus jij denkt dat ik beter alles in 1 tabel in kan voegen.. dit verhoogd de snelheid van me database?

nog andere opties of dingen die slim zijn om te doen?

[whoami]

Op maandag 18 maart 2002 12:00 schreef DiStance het volgende:
Anders: Dus jij denkt dat ik beter alles in 1 tabel in kan voegen.. dit verhoogd de snelheid van me database?

nog andere opties of dingen die slim zijn om te doen?

Het verhoogd zeker de snelheid. Anders heb je joins nodig om alle gegevens op te halen en nu doe je het met 1 select.

[LuCarD]

Op maandag 18 maart 2002 12:00 schreef DiStance het volgende:
Anders: Dus jij denkt dat ik beter alles in 1 tabel in kan voegen.. dit verhoogd de snelheid van me database?

nog andere opties of dingen die slim zijn om te doen?

Zorg ervoor dat je geen select * gebruikt aangezien je niet altijd alle data nodig hebt.

De tabel word nu groter en je zal nu eerder performance verlies gaan opmerken als je het wel doet.

[whoami]

Op maandag 18 maart 2002 13:22 schreef LuCarD het volgende:

[..]

Zorg ervoor dat je geen select * gebruikt aangezien je niet altijd alle data nodig hebt.

De tabel word nu groter en je zal nu eerder performance verlies gaan opmerken als je het wel doet.

Wil je dat eens nader toelichten? Hoe kan het aantal kolommen dat je selecteert nu de performance gaan beinvloeden? of je nu doet

code:

select tabel.veld1, tabel.veld2 from tabel

of

code:

select * from tabel

zal dat imo niet de performance gaan beinvloeden.

Het aantal rijen dat je ophaalt kan de performance wel beinvloeden. (Gebruik maken van WHERE clause, en goeie indexen leggen).

[Nielsz]

Op maandag 18 maart 2002 13:26 schreef whoami het volgende:

[..]

Wil je dat eens nader toelichten? Hoe kan het aantal kolommen dat je selecteert nu de performance gaan beinvloeden? of je nu doet

code:

select tabel.veld1, tabel.veld2 from tabel

of

code:

select * from tabel

zal dat imo niet de performance gaan beinvloeden.

Laat D2k het maar niet zien, die zal zijn l33t results laten zien van een test die hij hiermee heeft uitgevoerd

[whoami]

Op maandag 18 maart 2002 13:28 schreef Nielsz het volgende:


Laat D2k het maar niet zien, die zal zijn l33t results laten zien van een test die hij hiermee heeft uitgevoerd

Ik wil die wel eens zien

[LuCarD]

Op maandag 18 maart 2002 13:26 schreef whoami het volgende:

[..]

Wil je dat eens nader toelichten? Hoe kan het aantal kolommen dat je selecteert nu de performance gaan beinvloeden? of je nu doet

code:

select tabel.veld1, tabel.veld2 from tabel

of

code:

select * from tabel

zal dat imo niet de performance gaan beinvloeden.

Het aantal rijen dat je ophaalt kan de performance wel beinvloeden. (Gebruik maken van WHERE clause, en goeie indexen leggen).

code:

select * from tabel

Doet in principe twee queries
• Namen van de velden
• Data

Daarnaast haalt hij alle data op dus ook de niet relevante data. Aangezien we hem nu hebben verteld alles in 1 grote tabel te proppen ipv van 3 kleinere, zal je het verschil wel kunnen merken.
Als hij dan select * doet dan haalt hij 3 keer zoveel data op dan nodig is.!

[ACM]

Op maandag 18 maart 2002 13:33 schreef whoami het volgende:
Ik wil die wel eens zien

[topic=435488/1/100]

Daar ergens staat het wel

[D2k]

Op maandag 18 maart 2002 13:33 schreef whoami het volgende:
Ik wil die wel eens zien

ph34r m3

code:

test verslag
query1:
    $query="
        SELECT 
            id,
            topicid,
            userid,
            text,
            timestamp 
        from 
            forum_posts
    ";
query2:
    $query="
        SELECT 
            *
        from 
            forum_posts
    ";
    
aantal herhalingen:
25

uitgevoerd op www.happyfun.nl
aantal records: 6100

rest code:
    $result=mysql_query($query);
    while ($item = mysql_fetch_row($result))
    {
        //print_r($item);
        //echo "<br>";
    }   

resultaat: (3x ter referentie en vergelijk)

q1: 24.997175 21.859552 18.958795 |gemiddeld: 21.9385
q2: 35.081239 32.112438 31.418007 |gemiddeld: 32.9705

conclusie:
op 25 x 6100  records een verschil van  11.58 seconden!!!!!

[whoami]

Heb je daar ook een plausibele verklaring voor?

[Orphix]

Op maandag 18 maart 2002 14:44 schreef whoami het volgende:
Heb je daar ook een plausibele verklaring voor?

Ja ik heb daar de vorige keer ook vreemd naar gekeken. Je zou toch mogen verwachten dat een slimme database _eerst_ alle velden opzoekt (in dit geval maar van 1 tabel) en dan de rows gaat opzoeken... dus niet voor elk record de velden _weer_ opzoeken

[D2k]

Op maandag 18 maart 2002 14:44 schreef whoami het volgende:
Heb je daar ook een plausibele verklaring voor?

daar had ACM een verklaring voor
zal um ff deze kant op schoppen

[ACM]

Het had geloof ik met de inefficientere geheugen allocatie voor resultsets te maken.

Bij select X, Y, Z ... kan de optimiser pasklare geheugen gebieden alloceren voor elke row en/of het analyseren van de query.

Bij een select * weet de optimiser pas _na_ het uitvoeren/analyseren/etc van de query welke velden er beschikbaar gaan komen.

En sowieso moeten ook alle rows nog opgezocht worden etc etc.

[Verwijderd]

Ik ben iig een stuk geholpen... thnx guys..

Ik heb nu de tabel user en usergegevens samengevoegd.. ben alleen nog niet zeker of ik ook de tabel useraccount erbij moet voegen.. aangezien daar veel update queries op uitgevoerd zullen worden heb ik het idee dat dit sneller gaat als de tabel kleiner is? misschien een domme redenatie maargoed ben daar dus nog niet echt van overtuigd.. iig de user en usergegevens are united