SQL newbie: Wat voor systeem voor mijn MySQL databeestje
SQL newbie: Wat voor systeem voor mijn MySQL databeestje
Wat voor PC (Lees: hoeveel memory en hoeveel MHz rekenkracht) zou ik nodig hebben voor mijn SQL projectje.
Background story:
Op het werk hebben we een Access database waar we alle reparaties in registreren. In de loop der tijd is de database gegroeid, zowel in functionaliteit als in grootte. Resultaat: het hele spulletje begint irritant traag te worden. Zelf heb ik het probleem gelegd bij de trage werkstations waar we op werken. (Celeron 400 + 64MB PC66 systeempjes.)
Nu is de automatiseringsdrang bij ons op het werk nogal laag, dus snellere werkstations zit er de eerste 5 jaar nog niet in.
Om de rekenkracht voor een deel te verplaatsen van de werkstations naar een toekomstige server heb ik een testje gedaan met een eigen PC'tjs als SQL server (MySQL 4.0.14b). Hopeloos traag omdat het maar een Celeron600 is. Het interne geheugen van die PC *lijkt* wel voldoende (128MB).
Op de werkstations wordt MyODBC 3.51.06 ge-installeerd om zodoende de Access database als frontend te kunne gebruiken.
Alle tabellen ge-exporteerd naar MySQL. Nu is mijn datafolder ongeveer 3MByte.
We hebben een server van 1500MHz, (HP server TC4100) maar daar zet ik 'm liever niet op omdat daar al weer van alles opgezet wordt.(Winproxy, 6 printers, fileserver, ouwe mailserver, link naar hoofdkantoor via ADSL, gateway naar ISDN inbel, en nog wat zooi. Gek he, dat ie instabiel wordt)
Wat denken jullie wat ik voor PC nodig heb?
Background story:
Op het werk hebben we een Access database waar we alle reparaties in registreren. In de loop der tijd is de database gegroeid, zowel in functionaliteit als in grootte. Resultaat: het hele spulletje begint irritant traag te worden. Zelf heb ik het probleem gelegd bij de trage werkstations waar we op werken. (Celeron 400 + 64MB PC66 systeempjes.)
Nu is de automatiseringsdrang bij ons op het werk nogal laag, dus snellere werkstations zit er de eerste 5 jaar nog niet in.
Om de rekenkracht voor een deel te verplaatsen van de werkstations naar een toekomstige server heb ik een testje gedaan met een eigen PC'tjs als SQL server (MySQL 4.0.14b). Hopeloos traag omdat het maar een Celeron600 is. Het interne geheugen van die PC *lijkt* wel voldoende (128MB).
Op de werkstations wordt MyODBC 3.51.06 ge-installeerd om zodoende de Access database als frontend te kunne gebruiken.
Alle tabellen ge-exporteerd naar MySQL. Nu is mijn datafolder ongeveer 3MByte.
We hebben een server van 1500MHz, (HP server TC4100) maar daar zet ik 'm liever niet op omdat daar al weer van alles opgezet wordt.(Winproxy, 6 printers, fileserver, ouwe mailserver, link naar hoofdkantoor via ADSL, gateway naar ISDN inbel, en nog wat zooi. Gek he, dat ie instabiel wordt)
Wat denken jullie wat ik voor PC nodig heb?
-
- Posts: 1400
- Joined: 16 Jun 2003, 14:55
Het ligt er maar net aan hoeveel records en tabellen etc er in zitten en hoeveel queries er per dag / minuut / uur over heen worden gehaald..
Dat het systeem instabiel wordt dat hoeft niet daaraan te liggen.. is meer te wijten aan het OS > neem aan dat daar gewoon windhoos op staat? <
Een 1500mhz zou dat gewoon goed moeten kunnen dragen. Maar nogmaals, ligt aan de dbase, de queries, te tabellen etc (neem ook aan dat je er via een php oid een systeempje voor zet om gegevens in te voeren te verwijdern of te veranderen)
ik zie net staan dat je access als frontend gebruikt... weet niet of dat wel zo'n slim idee is, immers access is van zichzelf al een supertrtaag k*tprog.
Dat het systeem instabiel wordt dat hoeft niet daaraan te liggen.. is meer te wijten aan het OS > neem aan dat daar gewoon windhoos op staat? <
Een 1500mhz zou dat gewoon goed moeten kunnen dragen. Maar nogmaals, ligt aan de dbase, de queries, te tabellen etc (neem ook aan dat je er via een php oid een systeempje voor zet om gegevens in te voeren te verwijdern of te veranderen)
ik zie net staan dat je access als frontend gebruikt... weet niet of dat wel zo'n slim idee is, immers access is van zichzelf al een supertrtaag k*tprog.
idd om een goede beoordeling te kunnen geven is meer info nodig...
Er zijn databases die op een 486 met 16Mb goed draaien (maar dan heb je maar 1 tabel met 1 veld
), maar er zijn ook databases die op de zwaarste main-frames niet helemaal lekker meer draaien !
Wat je zei over die clients is niet waar: je hoort een database niet client-site te draaien, das jou fout!
Je had hem ge-exporteerd? Toen was hij 3Mb? Is data alleen de db-structuur of ook alle data?
En wat ook heel belangrijk is: hoe intensief wordt dat ding gebruikt? En dan met name op de piek momenten!
Er zijn databases die op een 486 met 16Mb goed draaien (maar dan heb je maar 1 tabel met 1 veld

Wat je zei over die clients is niet waar: je hoort een database niet client-site te draaien, das jou fout!
Je had hem ge-exporteerd? Toen was hij 3Mb? Is data alleen de db-structuur of ook alle data?
En wat ook heel belangrijk is: hoe intensief wordt dat ding gebruikt? En dan met name op de piek momenten!
3MB is met data. Geschatte gebruikers: 20. Hele grove schatting van de piekmomenten: 5 gebruikers die de database gelijktijdig raadplegen. Daarbij worden rapporten/formulieren gebruikt met per record een subrapport/formulier, soms 2.
Tabellen met aantal records en aantal velden (inclusief IDveld)
Dit zijn de intensief geraadpleegde en frequent gewijzigde tabellen:
HOOFDTABEL: 10669 records, 28 velden, 1738 Kbyte
Uren_volgnummer_linktabel: 7992 records, 5 velden, 486 Kbyte
Reparatieomschrijving_volgnummer_linktabel: 37612, 3 velden, 204 Kbyte
Materialen: 11735 records, 5 velden, 461 Kbyte
lookup tabellen (Of hoe je het ook noemen wilt) Deze worden meestal alleen maar gelezen, en sporadisch wordt er wat aan toegevoegd/gewijzigd.
Artikelen: 639 records, 5 velden
Artikelsoort: 5 records, 2 velden
Contactpersonen: 171 records, 2 velden
Faktuurstatus: 5 records, 2 velden
Klienten: 68 records, 2 velden
Materiaallijst 123 records, 6 velden
Reparatieomschrijvingen: 319 records, 2 velden
Technici: 26 records, 2 velden
Periode_datumtabel: 52 records, 4 velden
Ondertussen ben ik verder gegaan met experimenteren. Gelijk kom ik iets vaags tegen: Die MySQL service neemt idle wel 70% van de CPU time in beslag. Is dat normaal?
Tabellen met aantal records en aantal velden (inclusief IDveld)
Dit zijn de intensief geraadpleegde en frequent gewijzigde tabellen:
HOOFDTABEL: 10669 records, 28 velden, 1738 Kbyte
Uren_volgnummer_linktabel: 7992 records, 5 velden, 486 Kbyte
Reparatieomschrijving_volgnummer_linktabel: 37612, 3 velden, 204 Kbyte
Materialen: 11735 records, 5 velden, 461 Kbyte
lookup tabellen (Of hoe je het ook noemen wilt) Deze worden meestal alleen maar gelezen, en sporadisch wordt er wat aan toegevoegd/gewijzigd.
Artikelen: 639 records, 5 velden
Artikelsoort: 5 records, 2 velden
Contactpersonen: 171 records, 2 velden
Faktuurstatus: 5 records, 2 velden
Klienten: 68 records, 2 velden
Materiaallijst 123 records, 6 velden
Reparatieomschrijvingen: 319 records, 2 velden
Technici: 26 records, 2 velden
Periode_datumtabel: 52 records, 4 velden
Ondertussen ben ik verder gegaan met experimenteren. Gelijk kom ik iets vaags tegen: Die MySQL service neemt idle wel 70% van de CPU time in beslag. Is dat normaal?
Last edited by Laurindra on 02 Sep 2003, 12:59, edited 1 time in total.
Jah, daar ben ik dus ook achter gekomen, Maar omdat ik nog geen woord PHP kan schrijven zal dit voorlopig de front-end blijven. Als ik ooit ook PHP onder de knie heb, is dit het eerste projectg waar ik PHP ga toepassen. Tot die tijd zit ik met de bedrijfsgelicenseerde Office 97 opgescheept.Webkabouter wrote:ik zie net staan dat je access als frontend gebruikt... weet niet of dat wel zo'n slim idee is, immers access is van zichzelf al een supertrtaag k*tprog.
3 jaar geleden was Access97 al een mirakelse uitkomst voor mij en het bedrijf. Ik heb al heel wat mensen blij gemaakt met die database zoals die nu draait.madman wrote:Wat je zei over die clients is niet waar: je hoort een database niet client-site te draaien, das jou fout!
Nu ben ik weer ouder en wijzer geworden, en ja, nu zeg ik ook: Access97 zuigt zwaar als database, maar ik heb er wel mee leren omgaan. Vooralsnog doet ie het nog en het is beter als niets. Onze complete urenregistratie wordt erop gedraaid, fakturering van alle reparaties wordt erop uitgedraaid, waarbij automatisch uren- en materiaalkosten worden uitgerekend, enz. enz.
Ik ben dan nog wel een redelijke noob op databasegebied, maar op 'de zaak' ben ik bijna verheven tot databasegoeroe. En dat zegt weer genoeg over het automatiseringsnivo alhier.
Die dingen heten domeintabellenWhoCares wrote: ...
lookup tabellen (Of hoe je het ook noemen wilt)
...
Ondertussen ben ik verder gegaan met experimenteren. Gelijk kom ik iets vaags tegen: Die MySQL service neemt idle wel 70% van de CPU time in beslag. Is dat normaal?

MySql hoort helemaal niets te gebruiken in Idle: loop je instellingen ff na...
Heb je een schema van je database (PDM? of CDM?) Of is ie gewoon zo gegroeid? Als dat zo is raad ik je aan om een nieuwe "from scratch" te maken, voordelen:
- Je krijgt zo een goede stabiele database
- Kan veel preformance schelen (afhankelijk van het huidige ontwerp).
- Denk niet dat je nu foreign-key's gebruikt etc? of Indexes (clusterd of niet)
- Is je huidige database integer?
OK, het kost wat meer, maar op de langere tijd heb je er mee profijt van, zeker als hij nog gaat groeien/veranderen!
Er zijn hiervoor goede pakketten verkrijgbaar bijv. FCO-IM
Als je wilt kan ik je wel een keer op de club wat laten zien (wanneer is dat weer?)
Dan je fronted: je keuze voor php is geen slechte!! Vrij makkelijke scripting taal, maar het wordt wat lastigere als er ook grafieken gemaakt moeten worden... Kan wel hoor...