En databas per kund? eller alla kunder i samma databas? ex webbapp

Jag vet inte vad som är best practice, men jag tycker att det ska vara en gemensam databas för alla kunder.

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

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.

En cloud-lösning skiljer sig inte från en vanlig lösning på så hemskt många plan. Den stora skillnaden är att du på ett enkelt sätt kan lägga till nya servrar och på andra sätt hantera din uppkoppling etc. via enkla reglage på en hemsida. Problematiken med hur du delar upp dina databaser är ändå desamma.

Inte svar på frågan, men glöm inte att partitionera databasen för att öka prestandan. Följ länken ifall du använder MySQL.
Länk

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.

Vårt system är väldigt databasintensivt och mycket av logiken ligger i databasen snarare än i programkod vilket inte är så modernt längre men det är så det ser ut på många ställen och det är inget som går att ändra så lätt direkt. Modellen för själva datan är ganska lik även moderna system dock, förutom de som använder dokumentbaserade databaser som NoSQL och liknande, men det lämpar sig inte så väl för denna typ av system ändå.

Våra kunder har helt separerade databaser från varandra och det är inte på grund av några IT-relaterade orsaker främst utan att det är ett krav från både kunden och datainspektionen. Å andra sidan så hade allt blivit mycket mer komplext om vi hade samkört baserna i alla fall, olika kunder har ju olika specialanpassningar hela tiden som ofta innebär förändring av standardtabeller och dylikt. Det hade förstås gått att lösa om man hade tänkt på detta från början eller om man gör en ordentlig insats och bygger om allt, men det hade innefattat en massa extratabeller för kundspecifik information osv. och en sjuk massa mer logik i procedurer och liknande för att kunna hantera kundunika saker. De enda fördelarna med ett sånt upplägg som jag kan se är att kunder (alltså slutkunder, användare) skulle kunna administrera sina konton på en central plats för alla plattformar som vi står för och att vi hade fått en extra verifiering av kunddata då de ändringar som en användare gör på ett system skulle hamna i de andra automatiskt (exempelvis adressuppdateringar eller liknande). Våra kunder (alltså typ affärskedjor och liknande) är inte intresserade av att deras kunder ska kunna administrera konton centralt dock, snarare är det ofta väldigt viktigt att dessa sidor framstår som en del av deras egna webbplats.

Vad man skulle kunna göra är att lägga all persondata i en databas för alla kunder, och sen ha separata tabeller för allt annat, men det ger inga direkt fördelar och det hade blivit jobbigare att hantera på många sätt. Sen har vi ju ganska bra persondatabaser i Sverige, man kan (mot en kostnad förstås) koppla in sig på diverse register och få tillgång till API så man kan exempelvis verifiera namn och adress direkt från personnummer, alltså är nyttan med en samlad persondatabas ännu mindre för skatteverket och exempelvis SPAR (sveriges person och adressregister) har ju redan sådana. Separerar man databaserna kan man ju också se vilka som kräver mer prestanda exempelvis och flytta dem till en snabbare server eller uppgradera den de är på. Man kan också sprida databaserna efter användning så att om man exempelvis har en kund som gör väldigt mycket på dagarna och en på kvällarna kan man lägga dem på en server som räcker men som inte hade kunnat hantera hela lasten på en gång osv.

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.

Jo, fast jag tror vi pratar om lite olika saker. Om du säljer en produkt till slutanvändaren, typ som MS gör med Office, så är det ju förstås helt naturligt att du sparar data om dina kunder/användare i en databas, din egen. Samma om du har en tjänst som typ Dropbox eller liknande eller om man gör något mindre som ett hobbyprojekt eller så. Men ska du ha en produkt som säljs till företag som i sin tur ska låta sina kunder/användare använda den så måste du separera databaserna mellan dina kunder. Några kommer kanske att vilja köra det själva, några kommer att vilja att du arbetar fram en integrationslösning mot deras befintliga system (ofta flera olika från flera olika leverantörer) och några kommer bara att vilja köpa allt som en tjänst med databasadministration och allt. Du behöver förstås inte erbjuda alla typer av lösningar, men kunderna har ofta vissa väldigt fasta krav på strukturen (inte alltid så välgrundade) så om du inte kan leva upp till dem så spelar det ingen roll hur din lösning ser ut eller hur bra den är. Och att de äger sin data är i princip alltid ett krav, vilket gör en samlad databas till än ännu sämre idé.

Sen är det inte alls så att en jättedatabas skulle kräva mindre av servern den står på än en massa mindre. Databassystem (som SQL Server som vi använder) stöder ju många databaser på en server och en databas utspridd på flera osv. Virtualisering innebär också att man inte behöver ha dedikerade fysiska servrar till något alls egentligen utan man kan utöka och minska kapacitet och prestanda efter behov. Azure och Amazons moln bygger ju på sådan teknik fast i enorm skala.

Sen beror det förstås på vilken roll du tänker dig. Ska du bygga en produkt från grunden helt själv typ så måste du fundera på dessa saker ganska mycket men om du jobbar på ett företag som utvecklar en produkt så har de ju olika roller för olika uppgifter. Säkerligen en DBA som administrerar databasen, kanske en annan person som är ansvarig för datamodellen så att den hänger ihop med resten av produkten, så utvecklarna har ju vanligtvis inget att göra med typ vilken server som basen ligger på, eller exempelvis att skapa index för att förbättra prestandan i vissa utfrågningar osv. utan det är DBA-uppgifter. Precis som att fundera kring hur databasen ska läggas upp mest effektivt är en uppgift för den som ansvarar för datamodellen.

Det blir i många avseenden en fråga om affärsmodell. Tänker man sig att man ska göra kundanpassade lösningar eller en produkt som säljs till många företag.

Den kundanpassade lösningen kan, som många varit inne på, innebära att tillräckligt många parametrar skiljer sig åt vilket gör att det kan vara idé att ha separata databaser från början.

Vill man istället ha en produkt som är exakt likadan för alla kunder så ser jag inte direkt meningen med att ha separata databaser för varje kund.

Bara för att kunden är ett företag så innebär ju inte det att de kommer kräva en anpassning eller integrering mot andra system. Det finns ju både små och stora företag... När det väl kommer en kund som kräver anpassning så kan man fundera på om det är ekonomiskt försvarbart att utföra den. Därefter är det möjligt att vid behov lyfta ut delar i kundspecifika databaser.

Skickades från m.sweclockers.com

Är det software as a service du tänker på?

Jag tänkte inte på det specifikt, även om säkert mycket passar in.

Efter lite efterforskning så hittade jag ett par länkar som inte bara tar upp problematiken, utan även ger en definierar begreppen.

http://blogs.msdn.com/b/gianpaolo/archive/2007/01/25/cost-per-feature-vs-cost-per-tenant-or-how-to-choose-whether-to-go-multi-tenant-or-not.aspx

http://en.m.wikipedia.org/wiki/Multitenancy

http://msdn.microsoft.com/en-us/library/windowsazure/hh689716.aspx

Skickades från m.sweclockers.com

Tja, det beror väldigt mycket på omfattningen förstås. Har du ett antal företag som kunder som behöver några rader i några tabeller så är det inte så mycket att tjafsa om, men har du kunder som behöver miljontals poster så finns det ingen anledning att inte separera dem.

Om vi bortser från juridiska och avtalsmässiga skäl, och även anpassningar, så finns det fortfarande goda anledningar att inte samla kunderna i en databas, tänk exempelvis om en kund bestämmer sig för att göra en riktigt avancerad utsökning eller så och alla dina andra kunder plötsligt har en svarstid på en halvtimme istället för några sekunder, hur nöjda hade de varit då? Eller om en kund får för sig att ändra något på alla sina kunder i databasen så att man exempelvis får några miljoner poster i en standardsynkning som går kanske varje minut och som normalt har några enstaka kunder, då kanske den bulk-uppdateringen antingen låser hela kund-tabellen eller bara drar ner prestandan till någon enstaka procent av det normala för alla andra kunder, är det acceptabelt? Eller om man ska ha in en ny kund och då migrera in all dess data, ett jobb som kan ta ett antal dagar av konstant inläsning, hur glada blir de andra kunderna om de inte kan jobba under den tiden?

Sen blir ju själva utvecklingen av databasapplikationen mycket jobbigare (beroende på hur utvecklingen sker förstås). Vi har exempelvis en massa procedurer som ser exakt likadana ut i de olika kundsystemen men som gör olika saker beroende på ett antal parametrar som hämtas från en annan tabell men också beroende på vilken databas som proceduren körs ifrån och/eller vilket jobb som startade proceduren.

Tänk exempelvis en inläsning av en fil, det är ett jobb som kanske består av 20 procedurer. Den första kanske loggar in på kundens ftp och kollar om det finns filer att hämta, nästa kanske hämtar filerna till en in-katalog och lägger upp antalet filer och filnamn i en annan tabell. Den tredje kanske läser in all data från den första filen till en tabell, nästa kanske går igenom datan för att se att det är rätt typer osv., nästa kanske applicerar logik, nästa igen kanske validerar mot någon extern tjänst osv. och mot slutet kommer en procedur som kollar i fil-tabellen ifall det finns fler filer att läsa in och då börjar man från det steget igen. Allt det har kan göras av generiska procedurer som plockar parametrar från en tabell med exempelvis kundens ftp-info, vilka poster som ska finnas i tabellen, vilken extern tjänst som ska användas för validering, hur exempelvis kund-ID ska se ut osv. osv. Det går förstås att lösa även med alla kunder i en tabell, men det blir väldigt mycket svårare. Allt måste schemaläggas så att kund 1 inte försöker importera en massa kvitton exempelvis samtidigt som kund 2 försöker göra samma sak, eller samtidigt som kund 2 försöker hämta ut kvitton för att titta på dem. Det kanske inte låter så komplicerat men det är det nästan alltid och ännu mer så ifall kunderna har krav på snabbhet. En del av våra kunder kräver exempelvis att köp som görs ska läsas in var femte minut så att en användare aldrig ska behöva vänta mer än fem minuter tills dess att deras köp syns på deras köphistorik, det hade inte fungerat om man exempelvis har fem kunder på en databas och inläsningen riskerar att ta mer än en minut.

Sen blir ju logiken hela tiden mer komplicerad om man måste ta hänsyn till vilken kund datan gäller i exempelvis applikationskoden. Hur mycket mer komplicerat beror förstås på hur man kommer åt sina databaser från koden men mer komplicerat blir det alltid. Säg exempelvis att man ska göra ett enkelt filter för att hämta ut vissa personer, säg de som köpt en viss produktkategori för minst en viss summa under en viss vecka. Vet man att man bara har de kunder det gäller i den data man kommer åt från applikationskoden så är det ganska enkelt men måste man kolla ett visst värde för att se ifall det är ett som gäller just denna kund så blir det mer komplicerat direkt.

Frågan är då varför man skulle samla dem i en databas? Jag kan inte se några egentliga fördelar om det inte är så att man har väldigt små mängder data så att prestanda aldrig är ett problem osv. i vilket fall man kanske sparar en aning i driftskostnader. Men betalar du redan för en SQL-server så kostar det ju inte mer att lägga upp flera databaser på den serven liksom, och räcker inte det utan du behöver flera servrar så hade det blivit ännu jobbigare.

Jag håller med i väldigt många avseenden. Med sådana förutsättningar och krav så är det troligtvis bäst att ha separata databaser för varje kund.

Jag kan tycka att det låter som om ni lyft in väldigt mycket logik i databasen. Att scanna av en kunds FTP och läsa in filer till en katalog är t.ex. saker som jag hade lagt i en extern tjänst. Vidare så låter det ju som om det finns väldigt mycket anpassning per kund, vilket jag håller med om leder till att det troligtvis är bättre att ha en databas per kund i sådana fall.

Precis som du så tycker jag inte att sådan logik ska ligga i applikationen, men det finns ju många sätt att tackla det problemet, varav separata databaser är ett av dem. Ett annat sätt kan vara att sätta upp Views för varje tenant istället för att ha separata databaser. Som så mycket annat så är det en avvägning mellan när det blir jobbigare att separera datan logiskt mot att ha helt isolerade system.

Ofta är det precis det som är fallet. Små mängder data och prestandan blir aldrig ett problem. Då innebär det ju mest overhead att hantera ett stort antal likadana databaser.

Här är en länk till en mycket informativ artikel som trots sitt utgivningsår (2006) i mångt och mycket fortfarande känns aktuell. Den presenterar många för- och nackdelar med de olika alternativen och samtidigt många alternativa lösningar på säkerhet, etc.
http://msdn.microsoft.com/en-us/library/aa479086.aspx

Tack för en intressant diskussion. Jag tror vi har samma åsikt i många avseenden även om vi har två olika utgångspunkter. Det har varit högst intressant att höra hur ni tacklar problemen med era CRM-system.

Jag tror det är klokt att designa databasen så att det går att ha flera kunder i en instans. På samma sätt som det nog är bäst att ha en instans av backend som pratar med databasen osv. Då slipper man sätta upp separata saker till varje kund utan det blir enkelt att hålla alla uppdaterade utan en massa extra-jobb. En stor fördel är att det blir ett litet motstånd mot att göra speciallösningar till en enstaka kund, vilket är bra

I väldigt många system kommer det däremot snart inte gå att hålla allt samlat på ett praktiskt sätt av diverse anledningar, tex lagkrav, kunder som vill köra specialanpassningar eller kunder som vill ligga kvar på äldre versioner. Jag jobbade förut på ett betting/casino-företag, och då var vi tvungna att sätta upp separata instanser av ett system pga hur lagstiftningen skilde sig mellan länder, och givetvis dröjde det inte länge innan inte alla instanser var i synk. Har även jobbat med internetbetalningar, och där hade vi alla kunder i samma databas, trots vissa specialanpassningar till ett par kunder. Tror det hade varit mkt jobbigare om dessa special-kunder haft sina egna databaser. Ett enkel SQL-fråga för att ta fram hur mycket pengar det finns totalt i systemet skulle tex bli mycket lurigare.

Slutligen så är det med stor sannolikhet enkelt att flytta ut kunder till sina egna databaser senare om så skulle krävas. Att flytta ihop kunder är däremot svårt, speciellt eftersom dom nästan helt säkert har fått sina egna speciallösningar.

Jo, det finns förstås en massa situationer som kräver det ena eller andra eller som fungerar bättre på det ena eller andra och det beror väldigt mycket på vilken typ av applikation man har. Men pratar vi stora affärssystem och liknande med flera stora kunder så hade det varit katastrof för prestandan att behöva söka igenom alla kunders data hela tiden istället för bara den aktuella. Den minsta skillnaden som jag kan se i ett sådant system är att man får göra en extra utsökning vid varje utsökning, så att man bara får med det som gäller just den aktuella kunden. Typ om en enkel utsökning, för att få fram alla handelsbankens kunder som har gjort något igår eller senare, tidigare såg ut så här:

SELECT c.FNamn, c.ENamn, c.POAdress 
FROM Handelsbanken.Customer c 
WHERE c.LastTransactionDate > '20131118'

Så skulle det då, med en samlad databas, bli typ:

SELECT c.FNamn, c.ENamn, c.POAdress 
FROM Customer c
WHERE c.LastTransactionDate > '20131118' 
AND c.customerID = 
    (SELECT tc.customerID 
    FROM TypeCustomer tc 
    WHERE tc.CusName = 'Handelsbanken')

Det är ingen jätteskillnad men det är ju ett väldigt simpelt exempel och det tar säkert 30-40% extra tid att köra ändå. Hur prestandan blir med exempelvis Cursors som måste titta på varenda rad separat vill jag inte ens tänka på...