[jonny]

Jag kan se fördelar med olika databaser. Du kan fördela lasten och ha dedikerade maskiner per kund exempelvis. Du kanske har en kund som vill köra det själv etc.

Det går att låta scriptet automatiskt uppdatera databasen också utan större problem.

[dAEk]

Ett annat alternativ man kan diskutera är att ha en databas men dela upp kunderna i separata namespaces.

[dAEk]

Och med namespaces menar jag förstås scheman. Man kan på sätt och vis se scheman som databasernas motsvarighet till namespaces vilket förklarar att det slank igenom.

[patrikweb]

Beror helt på, är det samma grund applikation är det smidigare med 1 databas.

Men är det flera separat uppsättningar av applikation kan man lika väl köra separata DB, då får man vissa fördelar för anpassa unikt för 1 kund.

Men är det i grunden samma baskod/applikation för alla kunder känns det väldigt dåligt köra flera DB.

Idag går det skala DB väldigt kraftig, idag kan du köpa servrar med 4 x 16 core CPU och över 2TB ram. Känns inte precis problem med bygga en framtidssäker lösning där även med alla i 1 DB.

[pelmered]

Som någon var inne på tidigare beror det väldigt mycket på om du vill kunna sälja specialanpassningar och/eller sälja licenser så att företag kan hosta sin lösning själva. Vill du bara sälja en standardiserad tjänst med lite enkla moduler eller adons är det förmodligen enklare med en databas.
Men om du vill kunna sälja mer specialanpassade system för vissa kunder kan det vara bra att separera både databas och kodbas.
Se bara till att du har en core-kod som är samma på alla varianter. Den här core-koden bör du sedan versionshantera med exempelvis git så att du kan pusha eller pulla uppdateringar till kundernas core-branches. Ovanpå detta kan du sedan ha submoduler som kan vara helt olika för varje kund.

Skala kan man göra utan problem oavsett lösning som patrikweb sa. Man kan även skala en MySQL databas horisontellt(flera servrar) med ett NDB-cluster även om det bara är en enda databas. Det är inte jättekomplicerat att sätta upp.

[SEAPelle]

Det är mer jobb med flera Databaser men absolut ett bättre val.
Som flera varit inne på ur backup/restore, kundanpassning med mera.

Visst kan man skala upphårdvaran, men varför göra det om det inte behövs?
Självklart tar det längre tid att söka fram en bokning om du har 100 kunder med 20 användare och varje användare har 1000 bokningar efter några år (=2 000 000 poster i tabellen) jämfört med 100 databaser med 20 000 poster i tabellen samt att du slipper filtreringen på kundid. Det kommer gå åt mer prestanda för ett gemensamt system vilket gör behovet att skala upp hårdvaran kommer tidigare.

Då man som seriös utvecklare ändå har en testmiljö och färdiga produktionssättnignsscript går det lika lätt att köra de scripten på flera databaser som på ett enda. Du får desutom fördelen att kunna låta olika kunder betala serviceavtal för att alltid få senaste versionen medan andra kunder får stanna kvar på det gamla och efter några år betala klart högre uppdateringskostnad för att få alla uppdateringarna.

Lägger man sen till asopekten hur många hårddiskar det går åt för att ställa upp en ny MSSQL server enligt best practise e det klart billigare att behålla prestandan på en server och eventuellt komplettera emd någon enstaka disk.
Du kan dessutom öka prestandan massor genom att köra renodlat store procedures och även utnyttja CTE-tekniken och temptabeller på rätt sätt.
Själv hade jag en fråga (på typ 20 A4 sidor utskrivet) som byggde upp min slutkunds sortiment (Flera tusen kunder, hundra tusentals artiklar och alla har olika in och utpriser beroende på tidpunkter) som kördes varje natt och tog 4 timmar att köra. Efter två veckors finputsning av all SQL på exakt samma amskin och samma grunddata tar den körningen enbart 2 minuter idag. Ändå anser jag mig inte vara en expert på SQL, utan vill påvisa att man kan komma mycket långt enbart med att optimera sina egna saker...