Hvornår udskiftes Access med MS SQL el. MY SQL?

For mit vedkommende:

Da jeg fandt ud af, at det er langt nemmere end access at have med at gøre, når det gælder webløsninger. (Jeg bruger primært MySQL nu)

Derudover gjorde hastigheden også en del efter jeg skiftede. Sidst men ikke mindst, kan det nogle sql-sætninger, som Access ikke forstår, og som jeg ikke kan undvære nu.


Så mit råd: Skift nu!!

Jeg har aldrig lavet web løsning med Access.

Men noget grundliggende er:
  - Access er meget dårlig til flere samtidige brugere der opdaterer
  - fil databaser (som Access) er meget dårligere end database servere
    (som MySQL og MS SQL) når databasen ligger på en anden server end
    (web) applikationen

Det kan være gode performance grunde til at skifte.

Sikkerhed bør der ikke være nogen forskel på.

Access er vel nærmest nemmest at arbejde med fordi der er bundlet et
applikations værktøj med databasen.

thomas>

Jeg forstår ikke din betratgning om SQL funktionalitet.

MySQL er den ringeste database blandt alle kendte databaser
med hensyn til SQL understøttelse.

Jeg synes nu at MySQL (med MySQL Front) eller MS SQL (med Enterprise manageren) er en del nemmere en access at have med at gøre.

Det handler vel bare om at få installeret mysql/sql og ikke om hvornår man bør skifte. Access er ikke egnet til webløsninger.

Nu var det meget specifikt support for SQL sproget jeg gik efter. At
MySQL ikke understøtter diverse sub slects er et reelt problem.

Men jeg mener ikke at man kan sige at Access er uegenet til
web løsninger.

Hvis databasen ligger på samme server som web applikationen og det
er readonly adgang til databasen, så bør Access faktisk fungere udmærket
med selv en hel del load.

Access har nogle begrænsninger der gør at i en del tilfælde vil man
være nødt til at opdatere til en database server.

Tak for de indlæg der er kommet indtil videre..
Mht. om man kan lave en webløsning baseret på Access, så er jeg selv af den erfaring at det kan man sagtens, eftersom jeg har gjort det og løsningen også er baseret på skrivninger & opdateringer i basen og endnu ikke oplevet problemer.
MEN eftersom at jeg flere gang har hørt at Access ikke burde være så godt, så ville jeg gerne høre fra nogen som havde praktisk erfaring med at de blev nødt til at udskifte databasen af den ene eller anden grund.
Jeg synes personligt at det er nemt at lave webløsninger op imod en Access-database og at Access applikationen i sig selv er meget nem at anvende.

Ud fra kommentarerne indtil videre er de fleste enige om at det er bedre at skifte til f.eks. MySQL, at perfomrance her skulle være bedre og at funktionaliteterne er nogenlunde ens.

Men kan man f.eks. sige noget om at man ikke kan have mere end x antal brugere online samtidigt eller lign.?
Eller konkrete ting som:
* triggers
* crashrecovery
* roll back
* transactions

Andre ting kunne være:
* datatyper

eller:
* left, right, outer, inner joins

Du vil få problemer med Access og stor samtidig opdaterings aktivitet.

Jeg vil sige at mere end 10-20 brugere som laver heftig opdaterings aktivitet
så er Access's grænse nået. Bemærk at det vil være meget usædvaneligt
hvis 10-20 web applikations brugere kan generere 10-20 heftigt database
opdaterende brugere. Normal vil der skulle mange flete f.eks. 100-200
fordi de fleste web applikations brugere læser fra databsen og
holder pause mens mennekste i den anden ende læser.

Jeg mener at man siger 40-50 samtidige brugere kan det give problemer er grænsen, men har selv prøvet med en del flere (100-200) uden problemer.

Mht. datatyper har mysql/mssql en del flere. Ved nu ikke om det gør den store forskel i performance i mindre applikationer.

Både Access og MySQL har et rigt udvalg af data typer. Jeg synes måske at
MySQL er en tand bedre på det område.

Jeg mener ikke at der er den store fordel med hensyn til JOIN muligheder.

Jeg savner sub selects noget så forfærdeligt i MySQL.

Stored procedures, triggers, views osv. er en stor mangel i mysql, men det skulle efter sigende komme snart... det har de snart sagt længe.

Kan access egentlig overhovedet håndtere inner, left og right join??

MySQL kan du køre både på Linux og på Windows, så man har flere
muligheder der.

Med MySQL kan du splitte det ud på 2 maskiner - en med din applikation
(typisk ASP eller PHP) og en med din database. Det performer næsten
altid elendigt med Access, fordi en fil-database skal læse mange MB
og netværket bliver en flaskehals.

Det gode ved server-baserede databaser er også, at du kan få adgang til dem fra flere forskellige servere og er ikke afhængig af at have en database-fil liggende.

Ja - Access undertsøtter fint diverse joins.

Understøtter MySQL så også disse typer joins?

OG hvornår er det en fordel at have flere servere?

MySQL understøtter også disse joins.

Hvis en kombineret webapp og db server med 1 CPU har svært ved at klase
workload, så er det noget billigere at opgradere til 2 servere med hver
1 CPU - 1 til webapp og 1 til db, end at opgradere til en 2 CPU
kombineret server.

Arne -> Har du så nogen ide om hvornår det er relevant med 2 CPU'er (2 maskiner)?
Hvor stor workload snakker vi om? Har du nogle eksempler på sites der kører med mere end 1 CPU? Eller ideer om hvor mange samtidige brugere der potentielt kan give problemer med 1 cpu?

Det afhænger jo meget af hvad de brugere laver.

Men hvis man har en maskine i drift kan man jo undersøge CPU belastningen.

Hvis CPU konstant ligger og roder på 60-80-100% så kunne man jo nok
bruge noget mere CPU power.

Hvis den ligger på 0-20-40% så hjælper det næppe meget med en ekstra CPU.

Det har du selvfølgelig ret i. ;o)

Arne_V ->
Hvordan fungerer det / sætter man det op, når man kører med 2 servere som du beskriver?
Normalt synes jeg man i webapps ofte har problemer med at referere til filer der ligger fysisk på andre maskiner!?

Det er netop det der er forskellen på en fil-database og
en database server.

Med en fil-database angiver du typisk navnet på filen.

Med en database angiver du typisk IP nummer/navn og port.

Så er det jo nemt at referere til en anden maskine.