[php/MySQL] vraag over database structuur? - Softwareontwikkeling

maandag 28 januari 2002 18:57

Acties:

Verwijderd

Topicstarter

ik heb een x aantal variable die ik bewaar in een db,
wat is het beste?

1 grote table maken met daarin alle gegevens?

of de gegevens over 2 tabellen verdelen, hoelwel meestal alle gegevens nodig zijn, en ik dus 2 tabellen moet aanroepen?

ook nog een vraagje over de query's:
waarom zou je niet gewoon overal "SELECT * FROM"
i.p.v. "SELECT naam,ww,telnr, FROM" doen? (als je alleen de naam,ww,telnr nodig hebt.)

en wat betekent die "overhead" in phpMyadmin?? die rood staat aangegeven?

Data 3,888 Bytes
Index 3,072 Bytes
/me Overhead 96 Bytes
Effectief 6,864 Bytes
Totaal 6,960 Bytes

en als je een row vaak moet update'n maakt het uit of dat een grote table is of niet? (om de hits te tellen)

maandag 28 januari 2002 19:07

Acties:

Verwijderd

Op maandag 28 januari 2002 18:57 schreef ludohelder het volgende:
ik heb een x aantal variable die ik bewaar in een db,
wat is het beste?

Hangt af van de variabelen die je gebruikt, hoe vaak je ze nodig hebt en wat voor waardes ze kunnen bevatten

ook nog een vraagje over de query's:
waarom zou je niet gewoon overal "SELECT * FROM"
i.p.v. "SELECT naam,ww,telnr, FROM" doen? (als je alleen de naam,ww,telnr nodig hebt.)

Heeft te maken met de snelheid, als je alles opvraagt, dan duurt het langer, in werkelijkheid is dit niet echt van belang als je website maar 1 hit per dag heeft, maar als je net als hier heeeel veeel hits per dag hebt, dan kon het wel eens uit gaan maken (stel het scheelt 1 milliseconde, dan is dat bij 1 hit per dag niet zo'n ramp, maar bij 1 miljoen hits, wordt het toch wel wat irritanter --> 0,001 x 1000000 = 1000 seconden)

en wat betekent die "overhead" in phpMyadmin?? die rood staat aangegeven?
[..]

geen flauw idee, nog nooit van gehoord

en als je een row vaak moet update'n maakt het uit of dat een grote table is of niet? (om de hits te tellen)

Is denk ik het zelfde antwoord als hierboven

maandag 28 januari 2002 21:23

Acties:

Verwijderd

Op maandag 28 januari 2002 19:07 schreef doniek het volgende:
Is denk ik het zelfde antwoord als hierboven

ja, maakt uit, mysql zoekt namelijk naar de row die ie moet updaten, zitten er meer rijen in, zijn er meer id's die hij langs moet scannen, duurt dus langer... zal wel niet zo heel veel schelen, behalve als we spreken over een heeeeeeeele grote db... (GoT formaat)

maandag 28 januari 2002 22:29

Acties:

Rense Klinkenberg

<xml />

die overhead geeft dacht ik een soort defragmentatie aan van de bestanden.

maandag 28 januari 2002 23:05

Acties:

Orphix

Op maandag 28 januari 2002 21:23 schreef jurriebur het volgende:
ja, maakt uit, mysql zoekt namelijk naar de row die ie moet updaten, zitten er meer rijen in, zijn er meer id's die hij langs moet scannen, duurt dus langer... zal wel niet zo heel veel schelen, behalve als we spreken over een heeeeeeeele grote db... (GoT formaat)

En dus zet je er een index op. Maar in principe is deze vraag irrelevant omdat je als het goed is de data die je in 1 tabel hebt niet meer verder kan splitsen in 2 tabellen. Als je dat wel zou doen dan zou je in 2 tabellen moeten zoeken wat nog langer gaat duren.

Op maandag 28 januari 2002 22:29 schreef freak007 het volgende:
die overhead geeft dacht ik een soort defragmentatie aan van de bestanden.

Ja rows worden als een soort linked list opgeslagen. Wanneer je een row verwijdert zal er een stukje 'geheugen' ongebruikt blijven. Dit is dan je 'overhead'.

maandag 28 januari 2002 23:17

Acties:

Nielsz

2 tabellen aanmaken;
types:
-====-
id
name

values:
-====-
id typeId value

maandag 28 januari 2002 23:26

Acties:

tomato

[Hoe komen ze bij die overhead?]
Orphix: Ja rows worden als een soort linked list opgeslagen. Wanneer je een row verwijdert zal er een stukje 'geheugen' ongebruikt blijven. Dit is dan je 'overhead'.

Hmmm, het gebruik van linked lists lijkt me dit helemaal niet als gevolg hebben.

Ik zou het zelf meer in de richting van iets als fragmentatie zoeken (wat bij een OPTIMZE TABLE dus weer ongedaan gemaakt zou worden).
Maar misschien was het sowieso wel een beetje onzin, want volgens mij komt het in de huidige versies van phpMyAdmin niet meer voor (ik heb het idd ook ooit zien staan, maar ik kan het in de laatste paar versies eigenlijk niet terugvinden)

Zal zo eens in oude source zoeken, misschien dat ik daar wat wijzer uit kan worden...

[edit]
Het kan natuurlijk best zijn dat dit klopt en dat er ook een vorm van linked lists gebruikt wordt (ik vermoed het eigenlijk niet, maar wat weet ik nou van interne tabelformaten

), maar het is in ieder geval niet de oorzaak.

dinsdag 29 januari 2002 00:52

Acties:

Verwijderd

Als je het hebt over OPTIMIZE dan heb je het over de opslagstructuur van een tabel (ISAM, HEAP, ect.). Dit zorgt voor de minst mogelijke disk I/O's bij het uitvoeren van een query. Heb je overhead? Dan zijn de opslagstructuur-indexes niet meer helemaal optimaal. Volgens mij is dat getal dus de hoeveelheid data die niet meer optimaal te vinden is...

dinsdag 29 januari 2002 01:33

Acties:

Orphix

Op maandag 28 januari 2002 23:26 schreef tomato het volgende:
Hmmm, het gebruik van linked lists lijkt me dit helemaal niet als gevolg hebben.

Ik zou het zelf meer in de richting van iets als fragmentatie zoeken (wat bij een OPTIMZE TABLE dus weer ongedaan gemaakt zou worden).
Maar misschien was het sowieso wel een beetje onzin, want volgens mij komt het in de huidige versies van phpMyAdmin niet meer voor (ik heb het idd ook ooit zien staan, maar ik kan het in de laatste paar versies eigenlijk niet terugvinden)
Zal zo eens in oude source zoeken, misschien dat ik daar wat wijzer uit kan worden...

[edit]
Het kan natuurlijk best zijn dat dit klopt en dat er ook een vorm van linked lists gebruikt wordt (ik vermoed het eigenlijk niet, maar wat weet ik nou van interne tabelformaten ), maar het is in ieder geval niet de oorzaak.

Mjoah als ik het allemaal precies wist hing ik niet op GoT rond maar lekker op Hawai in m'n hangmat...

Maar zo had ik het begrepen. Bij het verwijderen krijg je inderdaad fragmentatie, de gegevens worden niet direct weggehaald, enkel de link naar die gegevens wordt verwijderd. Gevolg is nutteloze data, voordeel is een veel snellere DELETE.
Je verliest op deze manier snelheid bij normale SELECT's omdat het cachen minder nut heeft (als je de 100kb leest en alleen de eerste 50kb zijn echte rows 'verspil' je dus die laatste 50kb). Niet dat dit echt iets is om wakker van te liggen denk ik, maar af en toe een optimize kan nooit kwaad.

CMIIW

dinsdag 29 januari 2002 18:57

Acties:

Verwijderd

Topicstarter

dinsdag 29 januari 2002 20:17

Acties:

Janoz

Moderator Devschuur®

!litemod

Om je database structuur te maken zul je moeten normaliseren. Eigenlijk begin je dan met 1 tabel waarin alle gegevens staan. Deze ga je vervolgens omzetten in de 1e normaalvorm en de 2e en de 3e. (Als je dat al vaker gedaan hebt breng je hem meestal al gelijk naar de 3e normaalvorm).. Zoek hier eens wat over op (op inet of in boek)

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

woensdag 30 januari 2002 11:54

Acties:

Goodielover

Only The Best is Good Enough.

Janoz, zijn tabellen zijn genormaliseerd. Hij heeft ze alleen om performance redenen gespiltst.
Ze zou moeten kijken bij welke zware queries je welke velden nodig hebt en die eventueel bij elkaar in een tabel zetten. Als dit bijna geen winst oplevert omdat het bijvoorbeeld alleen van wat vlaggetjes zijn, kan je er beter 1 tabel van maken. Nu moet de DB namelijk in 2 tabellen zoeken voor bijna elke query en dat is zwaarder dan 1 keer in een grotere. Hij heeft dan in 1 keer alle waarden bij elkaar.