MySQL kontra Access

I dette tilfælde vil jeg sige det er ligemeget hvilken database du bruger. Access kan sagtens klare 10.000 poster, men det kommer også an på hvor meget søgning du laver og hvor indvikilet de er (mange joins, unions osv.)

Jo mere indviklet din søgning er, jo mere grund har du til at gå over til en "rigtig" database.

10000 poster er formentlig ingenting, men afhænger af størrelsen på en post
(hvis der er lidt INTEGER og VARCHAR så er det ingenting, snakker vi store
tekst eller binære objekter kan det være meget)

forudsat at Access databasen ligger på en lokal disk på din IIS server, så
er jeg ikke så bekymret over søgninger, men mange samtidige opdateringer er
den sikre måde at få Access performance til at gå i knæ

Der er 18 tabel og ca. 12 relationer til "hovedtabelen" så der vil jo komme en søgninger op flere kriterer

databasen fylder lige nu ca. 1,3 mb, og der kun fyldet ca. 10-15 % i den af info

Jeg har et par Access filer på +10 Mb og der er ingen problemer. Der har jeg ca 50 tabeller som alle er knyttet sammen på en eller anden måde.

Når jeg laver nogle af de indviklet søgninger, kan jeg godt mærke det, men normalt er der ingen problemer...

1.3MB er jo ingenting - du har sikkert 512 eller 1024 MB RAM i serveren, så
den vil ligge helt i memory

Og bare for at afklare hvor indviklet søgninger jeg har, så snakker vi om SQL-sætninger som fylder 20 linjer i min kode (2 unions med inner selects).

Har lige smidt den i word, og den siger 141 ord/959 tegn (uden mellemrum), for EN sql-sqlsætning. Den kan mærkes, men det tager stadig kun omkring 2 sek for siden at loade (mod normalt ½ sek. for de andre sider)

databasen kommer til at ligger hos web10, der er en del felt med notat, men her skal ikke søges, håber jeg :) alle relationer er jo med tal så det burde jo kunne funger uden de store SQL sætninger.
Lige et måske dumt spørgsmål !! :( er det ikke lige let at programmer til en MySQL som en access MDB fil ?

Det er de samme SQL-sætninger (kan være små forskelle) du skal bruge til at trække data ud/indsætte data i dine ASP filer. Så her er der ikke den store forskel.

Det er der derimod når du skal oprette din databse. Her har MySQL ikke indbygget et admin modul, som er lige så nemt at bruge, som det i Access. Så at oprette databasen (tabeller osv) er sværre/indviklet i MySQL end i Access.

Der findes dog mange 3. part admin systemer til MySQL (phpMyAdmin som en af de helt store), men jeg synes stadig ikke de er på højde med Access, men det er meget tæt på.

Et sidste spørgsmål
hvis nu at det viser at access bliver for langsom, hvor meget kan genbruge af programmering hvis  det skal flyttes til MySql,, export af tabel er ikke noget problem, det er selve asp siderne jeg tænker på ? bare sådan ca. et gæt i % hvis har en mulighed for at gætte.
På forhånd 1000 tak

hvis du koder i meget pænt standard SQL så retter du bare connection string

er det noget slam SQL kode kan du risikere at skulle rette hver eneste SQL sætning

Som vidreføring af arne-v..

select * from enTabel where enKolonne=123 order by enKolonne

Virker i begge database. Mens
"select Top 10 * from enTabel" er Access
"select * from enTabel Limit 10" er MySQL

Igen er vi ud i at jo mere indviklet SQL sætninger du har, jo større sansynlighed er der for at det ikke er cross-DB. Det du kan være 100% på er at datoer vil drille. Der bruger Access # til omkransning mens MySQL bruger ', desuden er formatet også forskellig:

"select * from enTabel where enDato=#12-31-2006#" (mm-dd-yyyy format i Access)
"select * from enTabel where enDato='2006-12-31'" (yyyy-mm-dd format i MySQL)

Der kan du dog være smart og sende dine datoer igennem en converterfunktion, som formatere dem rigtigt og smider # eller ' omkring. Så skal du kun ændre din funktion for at datoer virker, når du skifter DB.

jeg siger 1000 tak for hjælpe til jer,, :)
i skulle begge have point hvordan gør vi så det :)

Vi laver begge et svar, og her er mit. Så vælger du os begger på listen til venstre, og point bliver fordelt mellem os.
.o) <-- One Eyed Jack

svar

med hensyn til datoer saa kunne man forsoege med parameters

arne_v >>
Det er selvfølgelig også en mulighed :o)

Så skulle det være iorden,, medhensyn til dato, bruger ikke dette, inu har lavet det så man skriver 2006 - Marst eller 2006 - Januar.. osv
Igen takker og bukker for hjælpen :)