ik ben bezig een database op te zetten die later mayeb groot gaat worden, maar mijn vraag is. welke database programma door zoekt zo'n data base het snelst door? of zit er zoweingi verschil in dat het eigenlijk niet uit maakt?
Mja, maar in wat voor grootte moet ik dan denken?Op zondag 01 juli 2001 22:32 schreef -=[Terrorvis]=- het volgende:
soort forum/sharing progje. info databasje.
snappie?
jah aan het begin denk ik dat ut ff klein is maar hoorde al van een aantal mensen dat ze het willen gebruiken enzo.
en ik wil later dus niet hebben dat alels 1 maal goed draaid dat ik alles op niuew moet bouwen omdat de database het nie aan kan.
ok ga nu direct weer nei denken dat er direct of later 576578967893567 gebruikers op komen. maar denk zo'n 150 tot 250 gebruikers..
en ik wil later dus niet hebben dat alels 1 maal goed draaid dat ik alles op niuew moet bouwen omdat de database het nie aan kan.
ok ga nu direct weer nei denken dat er direct of later 576578967893567 gebruikers op komen. maar denk zo'n 150 tot 250 gebruikers..
mysql, snel, efficiënt en gratis
Kweenie of dat wel helemaal de beste keus is, maar om verwarring te voorkomen laat ik hem hier wel staan danOp maandag 02 juli 2001 04:45 schreef havana het volgende:
>> Hosting & Webserver Soft/Hardware
Verwijderd
Maar het gaat dus om een database die tegelijkertijd een forum en een los programma'tje moet bedienen?Op zondag 01 juli 2001 22:39 schreef -=[Terrorvis]=- het volgende:
jah aan het begin denk ik dat ut ff klein is maar hoorde al van een aantal mensen dat ze het willen gebruiken enzo.
en ik wil later dus niet hebben dat alels 1 maal goed draaid dat ik alles op niuew moet bouwen omdat de database het nie aan kan.
ok ga nu direct weer nei denken dat er direct of later 576578967893567 gebruikers op komen. maar denk zo'n 150 tot 250 gebruikers..
Hoe zwaar gaan die gebruikers de db belasten?
Op welk OS moet het gaan draaien?
Hoeveel geld wil je erin steken?
Zelfs de snelste database is traaaaaag als je code brak is.
Zekers als je in de toekomst zeer veel gebruikers verwacht is het een goede zaak om heel erg goed over de opbouw en opzet van je DB na te denken.
Zekers als je in de toekomst zeer veel gebruikers verwacht is het een goede zaak om heel erg goed over de opbouw en opzet van je DB na te denken.
Dat noemen ze ook wel normaliseren tot de 3e NVOp maandag 02 juli 2001 09:18 schreef The Source het volgende:
... een goede zaak om heel erg goed over de opbouw en opzet van je DB na te denken.
Verwijderd
Modjes? zoek es een ander topic om mee te ping pongen?
Database server qua snelheid maakt niet zoveel uit (goed je moet geen access pakken ofzo mgoed), maar met veel gebruikers moet je wel een beetje opletten wat voor server je pakt mysql is bv gratis maar heeft stukken minder features en beheer tools dan bv microsoft sql server, maar bij mssql heb je 1) een forse aanschaf prijs + prijs per database connectie die je wilt hebben dus als jij 150 concurrent gebruikers wil zal je een bijpassend license moeten kopen en dat kan best een beetje pijn doen in je portomonee..
Database server qua snelheid maakt niet zoveel uit (goed je moet geen access pakken ofzo mgoed), maar met veel gebruikers moet je wel een beetje opletten wat voor server je pakt mysql is bv gratis maar heeft stukken minder features en beheer tools dan bv microsoft sql server, maar bij mssql heb je 1) een forse aanschaf prijs + prijs per database connectie die je wilt hebben dus als jij 150 concurrent gebruikers wil zal je een bijpassend license moeten kopen en dat kan best een beetje pijn doen in je portomonee..
Soms is de 5e normaal vorm snellerOp maandag 02 juli 2001 09:23 schreef Hans het volgende:
Dat noemen ze ook wel normaliseren tot de 3e NV
Goh.. wordt er ge ping-pongt door de moderators ? Is deze thread vast de ping-pong bal
Back In Black!
"Je moet haar alleen aan de ketting leggen" - MueR
tenatmen normaliseren : 7.5. kan het welOp maandag 02 juli 2001 09:23 schreef Hans het volgende:
[..]
Dat noemen ze ook wel normaliseren tot de 3e NV
wow ik heet een ping pong topic gemaakt
maar goed denk dat ik gewoon simpel ding in mysql ga bouwen.
thanx voor de informatie.
Verwijderd
Die was toch niet zo heel geschikt voor als het heeel groot wordt? Zijn genoeg database-probleem topixjes over t.net over geweest toch?Op woensdag 04 juli 2001 09:44 schreef -=[Terrorvis]=- het volgende:
[..]
maar goed denk dat ik gewoon simpel ding in mysql ga bouwen.
zal ik? zal ik?Op maandag 02 juli 2001 11:14 schreef dusty het volgende:
[..]
Soms is de 5e normaal vorm sneller
Goh.. wordt er ge ping-pongt door de moderators ? Is deze thread vast de ping-pong bal
Klaar voor een nieuwe uitdaging.
Men zegt het, inderdaad. Feit is echter wel dat Tweakers & GoT (hoe groot was de database, 4 Gig of zo?) op PHP/MySQL draaien, en MySQL dus snel genoeg kan zijn bij hele grote databases, zolang de hardware maar niet de bottleneck vormt.Op woensdag 04 juli 2001 09:51 schreef Kerrick het volgende:
Die was toch niet zo heel geschikt voor als het heeel groot wordt? Zijn genoeg database-probleem topixjes over t.net over geweest toch?
Ik spoor veilig of ik spoor niet.
Verwijderd
4 GB is niet echt groot toch? al is het bij zo'n grootte wel leuk als je makkelijk kan repliceren, backuppenOp woensdag 04 juli 2001 10:40 schreef Anders het volgende:
[..]
Men zegt het, inderdaad. Feit is echter wel dat Tweakers & GoT (hoe groot was de database, 4 Gig of zo?) op PHP/MySQL draaien, en MySQL dus snel genoeg kan zijn bij hele grote databases, zolang de hardware maar niet de bottleneck vormt.
Verwijderd
Als je Microsoft, IBM en Oracle mag geloven, zijn resp. SQL Server, DB2 en 9i allemaal de snelste database. Aan de andere kant werd in een andere thread gezegd dat MySQL bekend staat als de snelste database. In andere artikelen staat dat PostgreSQL onder hoge load veel sneller en betrouwbaarder werkt dan MySQL.
Kortom, verwarring alom, en eigenlijk voornamelijk een 'appels met peren vergelijken' verhaal ... het enige waar mensen het overeens zijn is dat Access nooit snel zal zijn met grote sites
Het allerbelangrijkste is dat als je Good Software© maakt, dus dat je nadenkt over wat je wil doen, hoe je dat wil doen, wat de alternatieven zijn, en waarom je uiteindelijk voor een bepaalde oplossing kiest.
Zaken als:
- snelle hardware
- database tuning
- efficiente software
- cacheing
- schaalbaarheid
kunnen soms een veel grotere impact hebben dan naar een andere database systeem verhuizen.
Kortom, als je nog eens een discussie aan wil aangaan over goede software en wat dat is, en hoe je dat moet doen, lul ik graag wat mee, maar op deze vraag is helaas geen zinnig antwoord te geven.
Just my 2 cents ...
[acm-edit, © tekentje :P]
Kortom, verwarring alom, en eigenlijk voornamelijk een 'appels met peren vergelijken' verhaal ... het enige waar mensen het overeens zijn is dat Access nooit snel zal zijn met grote sites
Het allerbelangrijkste is dat als je Good Software© maakt, dus dat je nadenkt over wat je wil doen, hoe je dat wil doen, wat de alternatieven zijn, en waarom je uiteindelijk voor een bepaalde oplossing kiest.
Zaken als:
- snelle hardware
- database tuning
- efficiente software
- cacheing
- schaalbaarheid
kunnen soms een veel grotere impact hebben dan naar een andere database systeem verhuizen.
Kortom, als je nog eens een discussie aan wil aangaan over goede software en wat dat is, en hoe je dat moet doen, lul ik graag wat mee, maar op deze vraag is helaas geen zinnig antwoord te geven.
Just my 2 cents ...
[acm-edit, © tekentje :P]
Verwijderd
Volgens de TPC benchmark,
zie http://www.tpc.org/tpcc/results/tpcc_price_perf_results.asp
is SQL Server 2000 verreweg het snelste/$
Maar goed.. niemand hier heeft een server die daar bij in de buurt komt denk ik.. dus of dat reeel is/boeit verder weet ik ook niet.
zie http://www.tpc.org/tpcc/results/tpcc_price_perf_results.asp
is SQL Server 2000 verreweg het snelste/$
Maar goed.. niemand hier heeft een server die daar bij in de buurt komt denk ik.. dus of dat reeel is/boeit verder weet ik ook niet.
In sommige omgevingen boeit het niet zoveel of het 10x zo duur is, als het maar 5% sneller draait is alles best.Op dinsdag 10 juli 2001 00:20 schreef Kerrick het volgende:
verreweg het snelste/$
Ennuh... sorry, maar volgens mij worden op die link die je geeft niet alleen dbm's vergeleken, maar complete database systemen (dus incl de nodige hardware).
Tip:
Maak een "laag" tussen je script en je database. M.a.w. maak je script database independent. Ofwel, definieer zelf standaard functies die toepasbaar algemeen zijn voor elke database zodat je later alleen maar die functies heoft te wijzigen indien je van database wijzigt.
Zie evt. ook www.hotscripts.com
Maak een "laag" tussen je script en je database. M.a.w. maak je script database independent. Ofwel, definieer zelf standaard functies die toepasbaar algemeen zijn voor elke database zodat je later alleen maar die functies heoft te wijzigen indien je van database wijzigt.
Zie evt. ook www.hotscripts.com
Verwijderd
Ja en nee.Op dinsdag 10 juli 2001 00:27 schreef dirkpostma het volgende:
Tip:
Maak een "laag" tussen je script en je database. M.a.w. maak je script database independent. Ofwel, definieer zelf standaard functies die toepasbaar algemeen zijn voor elke database zodat je later alleen maar die functies heoft te wijzigen indien je van database wijzigt.
Zie evt. ook www.hotscripts.com
Het is inderdaad prettig als je systeem overdraagbaar is van 1 database naar een andere, maar er zijn 2 grote minpunten:
1) SQL is niet 100 % portable
2) als je iets kiest dat overal op werkt kan je juist de snelle truuks van een database niet gebruiken
Als je echt een heel snel systeem wil bouwen, maak dan een ontwerp, eerst functioneel, dan technisch, zodat je een goed idee hebt hoe je het gaat implementeren. Kies dan een database die op die features goed scoort, en optimaliseer je software / hardware / architectuur dan voor die database.
Verder is het heel vaak zinnig om over meerdere lagen te werken (3-tier / n-tier), maar dat is een kwestie van software architectuur en niet persee database onafhankelijkheid.
Verwijderd
Als je over zulke waanzinnige systemen praat heb je het altijd over een combi hardware/os/dbms.Op dinsdag 10 juli 2001 00:26 schreef tomato het volgende:
In sommige omgevingen boeit het niet zoveel of het 10x zo duur is, als het maar 5% sneller draait is alles best.
Ennuh... sorry, maar volgens mij worden op die link die je geeft niet alleen dbm's vergeleken, maar complete database systemen (dus incl de nodige hardware).
Vandaar mijn opmerking of dat nou wel boeit...
Verwijderd
Je kunt toch altijd voor 100% een database overpompen?Op dinsdag 10 juli 2001 00:35 schreef MrX het volgende:
[..]
1) SQL is niet 100 % portable
Het is misschien niet handig, maar een scriptje valt er altijd voor te schrijven, die bijv. een database eerst uitleest, verspreid over .txt files, en vervolgens een anders scriptje wat de .txt files weer in een andere db kan pompen..
Of zie ik dat verkeerd?
Verwijderd
Het gaat niet om het overzetten van gegevens, dat zal meestal geen probleem zijn (hoewel ... als je bijv. een SET kolom type gebruikt in MySQL en dan overgat naar een andere DB diet dat niet ondersteunt ...)Op dinsdag 10 juli 2001 00:41 schreef pim_ het volgende:
[..]
Je kunt toch altijd voor 100% een database overpompen?
Het is misschien niet handig, maar een scriptje valt er altijd voor te schrijven, die bijv. een database eerst uitleest, verspreid en verspreid over .txt files.
En vervolgens een anders scriptje wat de .txt files weer in een andere db kan pompen..
Of zie ik dat verkeerd?
Ik doelde meer op de queries. Zo zien JOINs er in Orackle bijvoorbeeld anders uit dan die in SQL Server en MySQL, en zo zijn er nog wel meer verschillen op te noemen. Als je queries dan her en der in je software staan ben je wel even zoet om dat allemaal aan te passen.
Of het boeit....tsja... Maar het ging me er meer om dat je daar dus niet aan kunt zien of SQL Server sneller is dan Oracle (zowiezo nogal een vage vraag).Op dinsdag 10 juli 2001 00:37 schreef Kerrick het volgende:
[..]
Als je over zulke waanzinnige systemen praat heb je het altijd over een combi hardware/os/dbms.
Vandaar mijn opmerking of dat nou wel boeit...
Het aanpassen zal vaak nog niet het grootste probleem zijn. Het zoeken naar waar de aanpassingen nodig zijn wel.Op dinsdag 10 juli 2001 00:44 schreef MrX het volgende:
[..]
Het gaat niet om het overzetten van gegevens, dat zal meestal geen probleem zijn (hoewel ... als je bijv. een SET kolom type gebruikt in MySQL en dan overgat naar een andere DB diet dat niet ondersteunt ...)
Ik doelde meer op de queries. Zo zien JOINs er in Orackle bijvoorbeeld anders uit dan die in SQL Server en MySQL, en zo zijn er nog wel meer verschillen op te noemen. Als je queries dan her en der in je software staan ben je wel even zoet om dat allemaal aan te passen.
Ach, als jij een in oracle draaidende DB hebt, die compleet op triggers en procedures leunt (die je liever in je DB hebt, dan als nog es een set extra queries, die naar je DB gepompt worden) dan wordt je er niet vrolijk van, om dat naar MySQL te porteren....Op dinsdag 10 juli 2001 00:46 schreef tomato het volgende:
Het aanpassen zal vaak nog niet het grootste probleem zijn. Het zoeken naar waar de aanpassingen nodig zijn wel.
Zelfs PostgresQL is dan nog een ramp
efficiënt: Keeps killing me everytime someone says that.Op zondag 01 juli 2001 22:45 schreef stylee het volgende:
mysql, snel, efficiënt en gratis
Back In Black!
"Je moet haar alleen aan de ketting leggen" - MueR
Vindt het overstappen van MSSQL SERVER naar ORACLE wel erg makkelijk. (anders om ook). Maar voor mysql, postgres etc. ga ik toch echt gewoon standaard SQL gebruiken, aangezien ik niet van plan ben om die databases voor altijd te gebruiken op het systeem waarop ik werk. DUS gebruik ik portable code waardoor ik makkelijk mijn code kan overzetten op een andere db. En dus ook pas specifieke sql kan gaan toepassen zodra ik een "definitief" db heb. (wat waarschijnlijk voorlopig niet zal gebeuren voor mijn eigen site..)Op dinsdag 10 juli 2001 07:34 schreef ACM het volgende:
Zelfs PostgresQL is dan nog een ramp
Back In Black!
"Je moet haar alleen aan de ketting leggen" - MueR
Pagina: 1