Skrivet av luddecraft:
... Som du säger så levererar du en uppsättning till kunden när de vill ha hand om hosting. Det är ingen större skillnad från din en-kund-per-databas-lösning.
Skrivet av SysGhost:
När det kommer till separata företag, har jag en fråga: Varför ens fundera på att de skall ha en gemensam databas? Om företagen inte har med varandra att göra, så är det ju rätt självklart att de är isolerade från varandra. Det även av säkerhetsskäl.
Nu är det här bara ett hypotetiskt exempel, men jag tycker att det är en viktigt fråga att ha klart för sig innan man börjar skissa på en databaslösning, då det måste vara med från börja. Många som inte har ett humm om hur databaser fungerar tror att man bara hipp som happ kan bygga om ett system baserat på ex "In House server" till en webbapp som kan användas mot massa kunder.
Varför jag funderar på det här är för att när/om jag får en jättebra idé till ett system/applikation;
då vill jag gärna göra den webbaserad så man kan sälja det som en tjänst, det verkar vara aktuellast och smartast.
Ex
http://www.speedledger.se/
http://www.projify.se/
Ja ni förstår.
Skrivet av Sidde:
Detta beror lite på hur du lägger upp säkerhetsmodellen. Antingen kan du styra behörigheterna per tex tabell, kolumn eller rad mellan kunderna eller styra det per databas.
Av säkerhetsskäl skulle jag ha en databas per kund just för att isolera miljöerna så mycket som möjligt och kanske ha en delad databas för applikationsspecifika funktioner. Men blir det för bökigt är det rätt smidigt att tex behörighetsstyra per rad osv.
Men jag skulle aldrig dela datat öppet mellan flera kunder, säg att du har lite "roliga" buggar i applikationen där ena kunden plötsligt kan se andra kundens data. Eller i andra lägen där en kund blir hackad så tappar du inte allt.
Precis, det är det här jag oroar mig för med en gemensam databas.
Det kräver ju i princip bara någon typo i koden för att query ska slå fel och visa massa data för andra företag.
Dessom måste man vara 100% säker på att skydda sig mot injection från alla håll och kanter.
Speciellt då ett intrång kan innebära problem för alla och inte bara en specifik kund.
Känns som en stor riskt att ha allt i samma databas.
Men jag förstår att ha en applikation och flera databaser blir klumpigt med, som Luddecraft säger:
Skrivet av luddecraft:
Det skulle skala fruktansvärt dåligt att sätta upp en databas per kund. Tänk 50 kunder = 50 databaser att underhålla. Därmed inte sagt att det skulle enbart vara en databas för hela systemet. Ofta har man t.ex. en separat databas för autentisering, auktoriserad, etc. Sedan så vill det ju till en hel del innan din databas blir gigantisk. Den dagen den blir det så har du antagligen så många kunder att du har råd att möta upp med hårdvara
.
Det skulle bli ett jäkla jobb att uppdatera många, kanske hundra - tusentals databaser.
Ingen enkel fråga alls, säkerheten är nummer ett, sen kommer prestanda och praktik.
Skrivet av snajk:
Jag jobbar med en produkt som består av stora databaser och ett (eller några) webbgränssnitt per kund men är ganska ny så jag har en del insikter om vad som är bra och så som många som har jobbat länge inte verkar se. Vår produkt är ett CRM-system och hanterar alltså typ medlemskap i kundklubbar med bonus osv. så kanske inte så väldigt likt ett bokföringssystem men det är en relationsdatabas med en massa olika kunder som i sin tur har en väldig massa slutkunder.
Jodå det är relevant, jag tog bara bokföring som ett exempel.
Det skulle kunna vara vilket system som helst egentligen.
Bokföring, projekthantering, CRM, ERP, eller något som ingen tänkt på innnan
Det är designfilosofin och problematiken jag är intresserad av, hur ska man tänka? är frågan.
Skrivet av SysGhost:
Fast frågan är: Skall du leverera "nyckelfärdiga" applikationer som företagen själva tar emot och sköter i eget hus? eller är det tänkt att du skall sköta allt åt företagen och "hyr ut" applikationen inklusive all administrering och husering?
Skrivet av snajk:
Att köra drift (servrar osv.) in-house gör man inte så mycket längre då det för det mesta blir mycket billigare att outsourca sådant och man slipper anställa eller hyra in spetskompetens för drift och liknande. Ytterst få företag har sådana mängder data eller så dataintensiva arbetsprocesser att det hade varit värt att ha en egen serverpark eller liknande och något mindre erbjuder inte samma säkerhet och redundans osv. Stordriftsfördelarna inom IT-drift är extrema. Det betyder dock inte att man lägger det i exempelvis Indien eller så utan snarare så brukar man försöka att hålla det inom landet av juridiska skäl.
Nu är det här hypotetiskt (och lite off-topic), men:
Vad det gäller servrar och hosting av applikationen skulle jag starta med inhyrd VPS/VPSer till en början för att senare flytta till den mest ekonomiska lösningen. Hyra dedikerade servrar alt Amazon EC2 eller liknande, i och med saker som EC2 och andra "moderna" hostingalternativ så ser jag inte det som ett stort problem, lite "den dagen den sorgen" eftersom om man har så pass med kunder så omsätter man nog pengar nog för att lösa det då
Uppkopplingen är i dag så pass bra världen över, så ska man inte streama film så spelar det egentligen ingen roll var servrarna står. Om man bortser från responstids-grejen, men det är sällan mer än 400ms som längst med fast lina och för ett informationsystem så är det acceptabelt.
Intressantare (och lite mer on topic ) är som snajk skriver om placering av databasen geografiskt pga juridiska skäl. Men återigen, när det blir ett problem borde man omsätta pengar nog för att lösa det problemet med pengar
tror jag i alla fall...
...som väntat...
Vi verkar ha två "camps" i huvudsak
1. Allt i en databas, men lite uppdelning för authentication.
2. Allt i separata databaser, men lite uppdelning för gemensamma funktioner.
