Kom ihåg mig?
Home Menu

Menu


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

 
Ämnesverktyg Visningsalternativ
Oläst 2014-02-10, 15:28 #1
ACarlsson ACarlsson är inte uppkopplad
Nykomling
 
Reg.datum: Aug 2007
Inlägg: 41
ACarlsson ACarlsson är inte uppkopplad
Nykomling
 
Reg.datum: Aug 2007
Inlägg: 41
Question 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
ACarlsson är inte uppkopplad   Svara med citatSvara med citat
Oläst 2014-02-10, 15:45 #2
ANttila ANttila är inte uppkopplad
Medlem
 
Reg.datum: Aug 2013
Inlägg: 81
ANttila ANttila är inte uppkopplad
Medlem
 
Reg.datum: Aug 2013
Inlägg: 81
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.
ANttila är inte uppkopplad   Svara med citatSvara med citat
Oläst 2014-02-10, 22:31 #3
KristianE KristianE är inte uppkopplad
Klarade millennium-buggen
 
Reg.datum: May 2008
Inlägg: 3 074
KristianE KristianE är inte uppkopplad
Klarade millennium-buggen
 
Reg.datum: May 2008
Inlägg: 3 074
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.
KristianE är inte uppkopplad   Svara med citatSvara med citat
Oläst 2014-02-11, 13:21 #4
ACarlsson ACarlsson är inte uppkopplad
Nykomling
 
Reg.datum: Aug 2007
Inlägg: 41
ACarlsson ACarlsson är inte uppkopplad
Nykomling
 
Reg.datum: Aug 2007
Inlägg: 41
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.
ACarlsson är inte uppkopplad   Svara med citatSvara med citat
Oläst 2014-02-11, 15:13 #5
danjel danjel är inte uppkopplad
Medlem
 
Reg.datum: Nov 2003
Inlägg: 214
danjel danjel är inte uppkopplad
Medlem
 
Reg.datum: Nov 2003
Inlägg: 214
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.

Senast redigerad av danjel den 2014-02-11 klockan 15:15
danjel är inte uppkopplad   Svara med citatSvara med citat
Oläst 2014-02-12, 10:24 #6
ANttila ANttila är inte uppkopplad
Medlem
 
Reg.datum: Aug 2013
Inlägg: 81
ANttila ANttila är inte uppkopplad
Medlem
 
Reg.datum: Aug 2013
Inlägg: 81
Citat:
Ursprungligen postat av danjel Visa inlä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?
ANttila är inte uppkopplad   Svara med citatSvara med citat
Oläst 2014-02-12, 21:22 #7
KristianE KristianE är inte uppkopplad
Klarade millennium-buggen
 
Reg.datum: May 2008
Inlägg: 3 074
KristianE KristianE är inte uppkopplad
Klarade millennium-buggen
 
Reg.datum: May 2008
Inlägg: 3 074
Citat:
Ursprungligen postat av ANttila Visa inlägg
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.
KristianE är inte uppkopplad   Svara med citatSvara med citat
Oläst 2014-02-12, 23:55 #8
tartareandesire tartareandesire är inte uppkopplad
Supermoderator
 
Reg.datum: Jan 2004
Inlägg: 11 585
tartareandesire tartareandesire är inte uppkopplad
Supermoderator
 
Reg.datum: Jan 2004
Inlägg: 11 585
Citat:
Ursprungligen postat av KristianE Visa inlägg
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
__________________
Full-stack developer, free for smaller assignments
tartareandesire är inte uppkopplad   Svara med citatSvara med citat
Oläst 2014-02-16, 19:55 #9
ACarlsson ACarlsson är inte uppkopplad
Nykomling
 
Reg.datum: Aug 2007
Inlägg: 41
ACarlsson ACarlsson är inte uppkopplad
Nykomling
 
Reg.datum: Aug 2007
Inlägg: 41
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.
ACarlsson är inte uppkopplad   Svara med citatSvara med citat
Oläst 2014-02-17, 11:26 #10
ANttila ANttila är inte uppkopplad
Medlem
 
Reg.datum: Aug 2013
Inlägg: 81
ANttila ANttila är inte uppkopplad
Medlem
 
Reg.datum: Aug 2013
Inlägg: 81
Citat:
Ursprungligen postat av KristianE Visa inlägg
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.
ANttila är inte uppkopplad   Svara med citatSvara med citat
Svara


Aktiva användare som för närvarande tittar på det här ämnet: 1 (0 medlemmar och 1 gäster)
 

Regler för att posta
Du får inte posta nya ämnen
Du får inte posta svar
Du får inte posta bifogade filer
Du får inte redigera dina inlägg

BB-kod är
Smilies är
[IMG]-kod är
HTML-kod är av

Forumhopp


Alla tider är GMT +2. Klockan är nu 20:23.

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