Menade inte riktigt så, om alla kunder ligger i samma db så finns ett starkt beroende mellan kod och data/datastruktur. Det blir då onödigt svårt (men givetvis möjligt) att låta en kund använda en kodbas/version av systemet och en annan kund använda en annan version.


Jo men då måste du utveckla funktionalitet för det, det kan ju vara så mycket som 30+ tabeller i ett system som detta, kanske med foreign key restraints m.m. som gör att deletes måste köras i en viss ordning..t.ex.. så då blir det enklare att köra DROP DATABASE x.
Poängen var inte specifikt att droppa en kund db, snarare att principen att logiskt separera data på olika db's för varje kund har fördelar vid både utvecklingsfasen och förvaltning / underhåll.

TextTak använder 1 databas för alla användare och det blir riktigt segt redan vid ett ca 2000 butiker.

Men det kan även bero på att de använder MySQL och inte modellerat databasen rätt.

Säkrast är att använda en databas för varje butik, men du måste då vara noga med att uppgradera alla databaser synkronserat.

Fördelen är att om en databas strular så kan övriga kunder fortsätta att köra. samt det blir lättare atat lastbalansera genom att flytta butiker till andra servrar när du får prestandaproblem.

En tredje variant är att u har en databas för nya kunder och att du har samma struktur i databasen, men har möjligheten att flytta ut enskilda butiker till egna databaser när prestandaproblem uppstår. Måttot är då optimal flexibilitet.

Det funkar med båda lösningarna men det är lite olika problembilder som man helst vill kunna styra individuellt för varje butik.