Hur lägga upp hyrlösningssystem? En databas, flera databaser?
 

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

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.

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.

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.

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?

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 :)

Tack för era svar än en gång!

Förstår vad ni alla menar, har kommit fram till att köra en databas med unika butiks id. Skulle det vara så att någon stor kund får för sig att använda systemet och inte vill vara hopblandad med de andra kan man ju enkelt skapa en egen databas för denna med endast en butik i, och helt enkelt anpassa efter kundens behov.

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.