Tja!
Har ett stundande projekt och i nuläget måste jag bestämma mig för vilken databastyp jag ska använda mig av.
Allt kommer skrivas i ASP och ska använda antingen Access eller MySQL till det här.
Applikationen kommer innefatta bla. >=150 användare som ska kunna logga in på sidan och därigenom få tillgång till viss information.
Det ska även lagras div. undergrupper (upp till 32st för varje huduvgrupp, totalt 3 stycken) alltså 3x32=96 grupper där 10 pers. ska kunna anmäla sig med div kontaktuppgifter, alltså 96x10 = 960 personers kontaktuppgifter som sak lagras.
Vidare kommer det sparas en del data till och jag har problem hurvida jag ska använda Access eller ASP till det här.
Ha sökt en del här på wF med blandade svar, vissa säger 5 samtidiga användare mot Access, vissa säger 10 och har även sett 64st.
Jag *tror* inte att alla dessa 150 användare kommer vara anslutnta samtidigt, but you never know....
Dom som ska ha den här Applikationen vill åt Access's exportfunktioner och jag har från början tipsat om Access, men det hela har vuxit en hel del och den datamängd som ska kunna lagras har ökat nå fruktansvärt, mot det som det talats om från början.
Så, vad ska jag göra?
Tack!
Hmm, ingen som har förslag?
Kan man på något sätt räkna ut på ett ungefär hur stor databasen kommer bli?
Säg att jag har en tabell med 10 Kolumner och ska där lagra minst 1000 personer, alltså 10.000 fält.
Måste verkligen veta ngt om det här innan jag kan starta, tack!
erkaMedlem sedan dec. 19996 522 inlägg Skippa access och sattsa på mysql. Access är enligt mig inte lämpat för den typen av applikationer
PaceMedlem sedan juni 20019 024 inlägg 1. Hur många kommer att använda datan under, ja, säg en timme?
(Om många ska koppla upp sig mot databasen samtidigt bör den klara det. Kom ihåg att en "uppkoppling" bara varar några hundradels sekunder i bästa fall.)
2. Vilken typ av data ska skickas?
(Är det video som ska skickas fram och tillbaka kan det ju krävas ganska mycket resurser. Några siffror klarar vilken databas som helst.)
3. Hur affärskritisk är datan?
(Om du inte har råd att förlora datan ska du inte satsa på något low-end-alternativ.)
4. Vad ska du göra i framtiden?
(Om du planerar tillväxt är det lika bra att göra det rätt från början.)
Nu tror jag att det blir bäst med MySQL, för att slippa ev. problem framöver, risken finns nämligen att det kommer bli stort, alltså många använda, mycket data osv.
Men, kan man på något sätt räkna ut hur stor i tex. MB en databas kommer bli, om man utgår från det ungefärliga antalet fält den kommer innehålla.?
UlfTMedlem sedan maj 20018 027 inlägg
MickeA.com skrev:
Kan man på något sätt räkna ut på ett ungefär hur stor databasen kommer bli?
Säg att jag har en tabell med 10 Kolumner och ska där lagra minst 1000 personer, alltså 10.000 fält.
Måste verkligen veta ngt om det här innan jag kan starta, tack!
Då vet du hur många fält du kommer ha totalt. Frågan är då vilka datatyper du tänker lagra i fälten. För vissa datatyper kommer du direkt kunna konstatera att de tar upp exempelvis fyra byte per fält. För en del andra datatyper, som varchar eller vad det nu kan heta i mysql, får du göra en bedömning av hur mycket text du förväntar dig kommer lagras normalt.
Hmm, ja, det är dom grejerna jag inte vet just nu, men det är inget "skumt" som ska sparas, så säg att på 12 Kolumner i en av tabellerna kanske 4 är TAL, 5 är TEXT och de sista av typen PM.
Nu har jag inte använt MySQL jättemycket tidigare, så kan inte dess Access motsvarighet.
@ndersMedlem sedan juni 200032 969 inlägg Men du måste ju veta vad du vill lagra för information?
@nders skrev:
Men du måste ju veta vad du vill lagra för information?
I det här skedet, nej, för jag vet inte exakt vad kunden vill ha för funktioner i nuläget.
Det kommer framgå efter ett möte v.10, men just nu har jag bara en viss aning om hur det kommer bli.
Men jag tror att man måste köra på MySQL, för det kommer förmodligen bli rätt stort i slutändan, sen är det ju bättre att "göra det för stort" till en början, istället för att behöva göra om halva applikationen när dom väl bestämt sig för att lägga till funktioner.
Hur är Exportmöjligheterna i MySQL? Har kollat lite hastigt från phpMyAdmin som jag har på min Unixserver här hemma och som det ser ut funkar det utmärkt att exportera som tex. ;-separerade filer eller som XML.
Allt som ska sparas i den här databasen kommer nämligen 4ggr om året exporteras och föras in i ett ekonomisystem, för vidare fakturering och bokföring.
spangoMedlem sedan juni 20008 205 inlägg Mitt spontana intryck är att datamängden borde inte vara något problem för Access (om det inte kontinuerligt kommer läggas till mycket data). Storleken på kontaktinformationen för en person lär som värst räknas i kB, och om du har information om 960 pers i registret kan du ändå ha c:a 1 MB per person och fortfarande bara vara uppe i hälften av Access datakapacitet, sist jag kollade (vilket förstås var ett tag sen).
Om det är 150 pers som kommer att använda den är det mycket, mycket osannolikt att de alla kommer att använda databasen på samma gång, men det beror förstås på användarmönstret. Om det verkligen finns anledning att tro att alla kommer att fippla med databasen vid samma tidpunkt kanske det kan vara motiverat att välja en mer potent databasmotor (typ MySQL), men jag vet inte... även om all trafik från alla 150 användare kommer inom en femminutersperiod borde det inte bli många samtidiga anrop.
Om de verkligen tycker att det finns en fördel med extra-gullegullfunktionerna i Access tycker jag nästan att du kan kosta på dem det. Eventuellt kan du ju konstatera för dem att det finns ett alternativ som kan ge bättre prestanda, men att exportfunktionerna kan bli lidande av detta. (Fast det är klart, exportfunktioner kan vara rätt enkla att fixa själv, om det bara är något i stil med csv-filer som ska exporteras...)
\r Jaså, du hann posta medan jag författade ;)
MickeA.com skrev:
Hur är Exportmöjligheterna i MySQL? Har kollat lite hastigt från phpMyAdmin som jag har på min Unixserver här hemma och som det ser ut funkar det utmärkt att exportera som tex. ;-separerade filer eller som XML.
Det är pissenkelt att fixa själv annars, bara du vet hur xml:en ska se ut. Csv finns det till och med medföljande program för till MySQL. Jag tror inte det är bra att ge dem direkt tillgång till phpMyAdmin eller liknande, dock.
spango skrev:
Jag tror inte det är bra att ge dem direkt tillgång till phpMyAdmin eller liknande, dock.
Nej, finns ingen anledning alls till det.
Den exporten skulle isf. ske av mig, som det ser ut just nu.
Som du säger ang, Access så vore det helt klart enklast men framförallt billigast, då MySQL kostar i startavgift och sen x antal kronor i månaden och det är ju något som dom kommer få ta ställning till.
Jag har gjort en annan grej, ett stort adressregister i Access, där databasen just nu innehåller >1400 adresser runt om i stockholm, just den tabellen består av 15 Kolumner. Vidare så finns ett gäng tabeller till, med åtminstonde lika mycket info, så databasen är "ganska" stor men sidan flyter på ruggigt bra iaf. och det har inte varit några som helst problem.
I värsta fall så får jag säga som det är, som du menar, att det går med Access i nuläget, men i framtiden kanske man måste byta till något annat.
Jag skulle gärna få fler svar ang. det här, så att jag på ett bra sätt kan lägga fram det och verkligen förklara på ett bra sätt vad det kan innebära att välja ditten eller datten.
Tack!
erkaMedlem sedan dec. 19996 522 inlägg Om det är för webben brukar ju inte webbhotell ta betalt extra för mysql. Det brukar ingå på de flesta paketen de erbjuder. Välj rätt från början, så slipper du göra om allting i en snar framtid
erka skrev:
Om det är för webben brukar ju inte webbhotell ta betalt extra för mysql. Det brukar ingå på de flesta paketen de erbjuder.
Inte hos Loopia, som jag alltid jobbar 'mot'.
