[ACarlsson]

Hej,

Jag är på väg och ska skapa en sorts hyr-system.

Jag kommer starta ett nytt system där vi kan ta tictail som exempel. Det jag undrar är hur jag ska lägga upp det när det gäller databas tänket. Användaren ska kunna registrera sig på hemsidan för systemet som man gör på tictail. De får sedan en egen (vi tar tictail som exempel) "butik". Ska jag då ha en databas för varje "butik". Eller ska alla "butikernas" information samlas i samma databas.

Kommer det kanske gå för segt att hämta uppgifter från databasen om man har ca 200 "butiker" i databasen som använder samma tabeller men hämtar data med sitt egna unika butiksid? Hur skulle ni ha lagt upp det?

Det ska alltså automatiskt skapas en ny "butik" direkt när man fyllt i sina uppgifter på hemsidan. Sedan ska man liksom tictail få en subdomän direkt och även kunna lägga till sin egen domän.

Kom gärna med följdfrågor om det jag skrev är otydligt.

/Anton

[ANttila]

Använd 1 databas. Du kan ha flera miljoner butiker utan att det blir segt, med rätt queries och index.

En tabell med users, en tabell med butiker.

[Conny Westh]

Ursprungligen postat av ANttila

Använd 1 databas. Du kan ha flera miljoner butiker utan att det blir segt, med rätt queries och index.

En tabell med users, en tabell med butiker.

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.

[KristianE]

Jag skulle nog hellre dela upp med en databas med butik. För om något händer med en butik och du behöver göra en restore - eller liknande - så sänker du inte alla kunder.

[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.