[ACarlsson]

Tack för era svar.
Min tanke är liksom ANttila att det är bättre med en databas. Då går det smidigare att lansera nya funktioner, ha koll på statistik för alla butiker m.m.

Vill gärna ha fler åsikter kring detta om det är någon som har erfarenhet av denna typ av upplägg.

[danjel]

Om jag skulle göra en enterprise lösning och hade tid skulle jag välja en databas per butik. Kanske initialt medsamma kodbas för varje kund, men att det finns flexibilitet för att låta vissa kunder använda en annan version av koden.
Då kan man enklare ha olika versioner av butiksystemet för olika kunder, en viss kund kanske vill en en ny modul medans en annan inte vill det.
Samt man kan enklare hantera respektive butik, t ex bara droppa databasen om de inte längre är kund. Vissa delar av utveckling blir även enklare, man behöver inte hålla reda på butiks id i varje sql fråga exempelvis.
Men såklart uppdateringar och summeringar/statistik blir då svårare generellt.

[ANttila]

Ursprungligen postat av danjel

Om jag skulle göra en enterprise lösning och hade tid skulle jag välja en databas per butik. Kanske initialt medsamma kodbas för varje kund, men att det finns flexibilitet för att låta vissa kunder använda en annan version av koden.
Då kan man enklare ha olika versioner av butiksystemet för olika kunder, en viss kund kanske vill en en ny modul medans en annan inte vill det.
Samt man kan enklare hantera respektive butik, t ex bara droppa databasen om de inte längre är kund. Vissa delar av utveckling blir även enklare, man behöver inte hålla reda på butiks id i varje sql fråga exempelvis.
Men såklart uppdateringar och summeringar/statistik blir då svårare generellt.

Om du har en framtida version av butiken som kräver en helt annan struktur på databasen så har du inte gjort databasen tillräckligt modulär från start, men det är ju så klart mänskligt.
Droppa en hel databas istället för DELETE...WHERE id = 123 ???
För mig som programmerare är det ingen problem att hålla koll på vilken butik jag arbetar med osv.

Varför inte lägga alla butiker i samma tabell, istället för en ny tabell(databas) för varje?
Vad är det som ska lagras egentligen. Det är väl bara lite rubriker(VARCHAR) och några textstycken(TEXT) som ska lagras?

[KristianE]

Ursprungligen postat av ANttila

Om du har en framtida version av butiken som kräver en helt annan struktur på databasen så har du inte gjort databasen tillräckligt modulär från start, men det är ju så klart mänskligt.
Droppa en hel databas istället för DELETE...WHERE id = 123 ???
För mig som programmerare är det ingen problem att hålla koll på vilken butik jag arbetar med osv.

Varför inte lägga alla butiker i samma tabell, istället för en ny tabell(databas) för varje?
Vad är det som ska lagras egentligen. Det är väl bara lite rubriker(VARCHAR) och några textstycken(TEXT) som ska lagras?

Tills dess du får Stora-Handlaren (tm) som kund och de självklart kräver att absolut inte
beblandas med andra kunder. Om TS satsar på att komma långt med denna tjänst så bör
kundisolering vara självklart från start. Vad du som programmerare tycker är faktiskt ganska
ointressant i sammanhanget. Det är business och då blir teknik helt ointressant.

Verksamhetens krav väger mycket tyngre. Lite hårda ord kanske, men jag är själv gammal
tekniker och vet precis hur ointressant det är om jag lägger fram den ena (fräcka) tekniska
lösningen efter den andra som inte passar verksamheten.

[tartareandesire]

Ursprungligen postat av KristianE

Tills dess du får Stora-Handlaren (tm) som kund och de självklart kräver att absolut inte
beblandas med andra kunder. Om TS satsar på att komma långt med denna tjänst så bör
kundisolering vara självklart från start. Vad du som programmerare tycker är faktiskt ganska
ointressant i sammanhanget. Det är business och då blir teknik helt ointressant.

Verksamhetens krav väger mycket tyngre. Lite hårda ord kanske, men jag är själv gammal
tekniker och vet precis hur ointressant det är om jag lägger fram den ena (fräcka) tekniska
lösningen efter den andra som inte passar verksamheten.

Det är snarare så att du talar om två olika målgrupper. "Stora-Handlaren" vill nog hellre ha full kontroll själv och då är inte denna lösning särskilt intressant utan det passar bättre att sälja en vanlig e-butikslösning. Det här handlar snarare om en billig, smidig lösning för mindre e-handlare och då gäller det att hålla nere kostnaderna så mycket som möjligt och istället satsa på volym. Business och teknik hänger alltid samman vilket du verkar bortse från

[ANttila]

Ursprungligen postat av KristianE

Tills dess du får Stora-Handlaren (tm) som kund och de självklart kräver att absolut inte
beblandas med andra kunder. Om TS satsar på att komma långt med denna tjänst så bör
kundisolering vara självklart från start. Vad du som programmerare tycker är faktiskt ganska
ointressant i sammanhanget. Det är business och då blir teknik helt ointressant.

Verksamhetens krav väger mycket tyngre. Lite hårda ord kanske, men jag är själv gammal
tekniker och vet precis hur ointressant det är om jag lägger fram den ena (fräcka) tekniska
lösningen efter den andra som inte passar verksamheten.

Om en kund vill ha en egen server, visst, lägg upp det åt dom för ett litet specialpris. Båda parter blir nog glada.
Om en kund vill använda tjänsten som alla andra så måste den butiken vara med i tjänstens system.

[danjel]

Ursprungligen postat av ANttila

Om du har en framtida version av butiken som kräver en helt annan struktur på databasen så har du inte gjort databasen tillräckligt modulär från start, men det är ju så klart mänskligt.

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.

Ursprungligen postat av ANttila

Droppa en hel databas istället för DELETE...WHERE id = 123 ???
För mig som programmerare är det ingen problem att hålla koll på vilken butik jag arbetar med osv.

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.