WN

WN (https://www.wn.se/forum/index.php)
-   Serversidans teknologier (https://www.wn.se/forum/forumdisplay.php?f=4)
-   -   Hur lägga upp hyrlösningssystem? En databas, flera databaser? (https://www.wn.se/forum/showthread.php?t=1060788)

ACarlsson 2014-02-10 15:28

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

ANttila 2014-02-10 15:45

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.

KristianE 2014-02-10 22:31

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 2014-02-11 13:21

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 2014-02-11 15:13

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 2014-02-12 10:24

Citat:

Ursprungligen postat av danjel (Inlägg 20486314)
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 2014-02-12 21:22

Citat:

Ursprungligen postat av ANttila (Inlägg 20486357)
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 2014-02-12 23:55

Citat:

Ursprungligen postat av KristianE (Inlägg 20486438)
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 :)

ACarlsson 2014-02-16 19:55

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.

ANttila 2014-02-17 11:26

Citat:

Ursprungligen postat av KristianE (Inlägg 20486438)
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 2014-02-20 16:16

Citat:

Ursprungligen postat av ANttila (Inlägg 20486357)
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.


Citat:

Ursprungligen postat av ANttila (Inlägg 20486357)
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.

Conny Westh 2014-02-20 16:50

Citat:

Ursprungligen postat av ANttila (Inlägg 20486235)
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.


Alla tider är GMT +2. Klockan är nu 08:50.

Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson