Begrænsninger ved My Sql

Alle svar man kan give om mysql, vil være meget afhængige af den konkrete database (tabellernes definitioner) og de data du hælder i den, men her er nogle bud på de overordrende svar...

1) Man kan uden videre have flere hundrede megabyte af data, men en god regel kunne hedder, at  jo flere data du hælder i den, desto bedre skal du kende den for at kunne bruge den ordenligt. Mysql er rimelig fornuftig på en standard installation, så der kan de fleste saktens hælde 50 Mb ind uden det går helt galt. De største mysql'er jeg har arbejdet med ligger omkring 2Gb data fordelt på ca. 20 tables og flere hundrede tusinde rækker i tabellerne - stadigt med svartider på under 0.1 sekund.

2) Hastighed. Tja.. Det kommer jo an på... Mysql udviklerne plejer normalt at måle sig mod Oracle, DB2 og lignende databaser - altså den professionelle liga (modsat Access, der er velegnet til amatører). Mysql er specielt hurtig til læsninger, og langsomere (relativt set i forhold til andre databaser) til skrivninger (nye rækker samt opdateringer). Dette forhold er blandt andet det, der har gjort den meget brugt til webløsninger, hvor man ofte har flere hundrede læsninger for hver skrivning.

3) Flerbrugere. Min erfaring er igen, at det ikke er mysql men din webserver, der giver op først. Normalt vil hver webserver proces bruge en database forbindelse. Jeg har set mysql håndtere op mod 100 database connections (skrivninger) på en enkelt maskine (en cpu, men en masse ram), og har endnu ikke prøvet at komme i kø eller blive smidt af.
--
Når man udvikler applikationer, der bruger mysql, er det normalt en god ide at sætte sig ind i hvordan den fungere - der findes en række rimeligt simple tricks, der kan øge performance, hvis man bruger dem. Et råd er blandt andet at undgå variable felt-størrelser på "ofte anvendte tabeller", hvis det kan lade sig gøre (f.eks. ved generelt altid at bruge chars fremfor varchars). Herudover gælder at om at lave et "balanceret" antal indexes på de felter, man søger på (for mange indexes gør inserts og updates langsomme).

Regn som udgangspunkt med at alle søgninger i en enkelt tabel (med under 10.000 rækker) aldrig bør tage over 0.01 sekunder og 2-3 tabeller (igen med op til 10.000 rækker) kørt sammen i en søgning aldrig bør tage meget over 0.02 sekund. Gør de det skal der kigges på indexes, måden sql'en skrives på eller ligende (se forklaring på "explain" ifm. sql-statements i mysql-manualen, hvis du ikke kender den).
--
Skulle det ske, at mysql virker "langsom", findes der mange muligheder for - rent hardware mæssigt at gøre noget, f.eks. flytte mysql-databaser ud på en anden (fysisk) harddisk end resten af styresystemet, sætte mere RAM i maskinen, sprede tabellerne i flere databaser og lignende, men alt det burde først for alvor blive aktuelt, når du har _rigtigt meget_ trafik på det site, der anvender din mysql.

er den teoretiske grænse for data ikke omkring 4 TB ?

Det kommer an på flere ting - blandt andet det filsystem mysql'en er installeret på og om man kører mysql 3.x eller mysql 4.x. For de fleste installerede mysql'er, ville jeg i praksis forvente den lå omkring 2Gb pr database, men man sjældent ville nå den i praksis, da performance burde falde og man derfor ville fordele tables i flere databaser (på flere diske) om muligt.

Du kan også komme med det argument at han senere skal bruge tid og penge på at flytte væk fra Access, så hvorfor ikke gøre det med det samme?

Access er fint til din private pladesamling, men regner han med at få et website der er bare en smule besøgt kan det ikke betale sig at tage omvejen forbi Access.

Ellers har mahler givet nogle fornuftige og godt forklarede argumenter.

Mange tak for indlæggene, specielt mahler!

Lige et sidste afsluttende spørgsmål: Den føromtalte gut har selv programmeret et rimeligt omfattende site helt fra bunden, hvilket vil sige, at han først har lært sig selv at kode (asp)... Derfor vil der klart være nogle flaskehalse i koden, som har indvirken på performance...

Er der nogen, som er friske på at give et bud på, hvor meget han vil få ud af at skifte til MySql, hvis man indtænker alverdens performance-begrænsninger i koden, fremfor hvad han vil få ud af at bruge systemet, som det er nu (med Access) som en første generation og skifte denne ud med en professionel løsning, når successen indtræffer (altså mange besøgende på sitet)?? Hvor meget vil en ren udskiftning af Access med MySql give contra de problemer det vil give i en kode totalt uden brug af lagdeling og standarder (her tænker jeg på den lidt forskellige implementation af SQL i Access og MySql)...

Jeg ville råde til hvis site har mere end 10 besøgene på en gang at du bruger MySQL da Access så ikke længer kan følge med for der må være 10 conn. til en Access database på en gang mere kan den ikke klare jeg kender ikke tallet for MySQL men hvem det skal ganges mange gang har selv lavet et site til Access som jeg er ved at lave om.

hmm....

Hvis man nu var microsoft fan burde svaret naturligvis være, at man burde holde fast i Access, og når det blev relevant med en opgradering, fordi Access ikke længere kan følge med, så burde man (i teorien) uden videre kunne udskifte Access med Microsoft SQL Server. Der findes trods alt større sites, der kører på ASP (Jubii.dk, Microft.com, etc.)

Problemet med dette er naturligvis, at det koster en hel del at erhverve licenser til dette, når tiden kommer.

Udover dette, så har Access faktisk også nogle fordele fremfor Mysql - blandt andet end bedre SQL-implementering (der ligger tættere op ad mysql-standarden - hvem sagde subselects).

"Key selling points" for mysql plejer normalt at være, at (1) det koster ikke noget, hvis sitet vokser (i licenser), (2) det er nemmere at finde (gratis) support til Mysql, (3) der er mange flere, der sidder med problemer, der ligner ens egne (server, udviklingssprog, trafikvolumen, etc.) på en mysql baseret platform og (4) det er meget nemmere at få "automatisk" solid performance ud af mysql end ud af nogen anden database.

Jeg takker for hjælpen! Sammen med indlæggene i Access spørgegruppen, har jeg fået nok konkret data til at kunne give manden en ordentligt vejledning... :)