OT: SQL Server fråga

Tråden skapades och har fått 2 svar. Det senaste inlägget skrevs .
1

Vet inte riktigt om denna fråga skall anses vara off-topic men jag hoppas att någon trevlig SQL-guru kan ge mig lite vägledning.

Jag håller på med en webshop och försöker nu bestämma mig för vilken väg jag skall gå. Det är en riktigt fet lösning baserad på SQL Server.

Som den är konstruerad är den byggd att ha en butik, men ägaren vill kunna husera flera butiker i samma lösning. Som jag kan se det finns det två sätt att göra detta.

1. Lägg till en kolumn "Account" och märk alla rader i tabellerna med det ett ord i den kolumnen som identifierar butiken. På det viset så vet man vilken kund/produkt/order/orderrad mm som hör till vilken butik. Man jobbar helt enkelt vidare med samma tabeller i de tre databaser som lösningen består av nu. Det finns en del fördelar med detta och det är att vissa uppgifter (som tex sortimentet hos distributörer) kan delas lätt mellan butikerna och inte behöver importeras flera gånger, en gång till varje butik. Man öppnar alla filer och ser till att de överallt använder sig av account för sökningar, skapandet av rader i tabeller mm. Nackdelen jag kan komma på är att alla butikers kundregister finns i samma databas och den dagen en kund vill flytta och ta med sina uppgifter blir det lite yxigt.

2. Man skapar nya databaser med samma struktur som de som redan används. Sedan öppnar man alla filer och säger åt dem att prata med dessa databaser istället. Det betyder att varje butik har tre databaser med ett otal tabeller i.

Aftonbladet eller Expressen?
----------------------------------------------------------------
Vad jag undrar över är förstås vilken väg som är bäst att gå, skall man satsa på att bara ha tre databaser och 1-100 butiker i dem eller skall man satsa på att ha 3-300 databaser med en butik för varje tre databaser? Vad är klokast om man funderar på prestanda, underhåll, säkerhetskopiering, vidareutveckling av lösningen med nya funktioner som tex ett nytt "Stored Procedure", säkerhet, kunders känsliga uppgifter osv...

Vad jag kan se så måste varje butik hur som helst ha sin egen uppsättning med filer, just nu är det ett antal filer som är shoppens ansikte utåt och ett antal filer till som är administrationen av shoppen. Med 100 butiker blir det med båda metoderna en väldans massa filer att ändra i med det är ungefär lika jobbigt oavsett vilken av metoderna som används.

Någon som har några goda råd?

Med vänlig hälsning

Ola Andersson

  • Medlem
  • Stockholm
  • 2002-02-19 21:37

Det går framåt märker jag.

Det finns andra lösningar än dessa.. Massa fina joins och sådant..

Men eftersom ni använder MSSQL7 (tror jag ni fortfarande har, eller har ni optimerat koden för 2000?) Så skulle jag nog faktiskt för att underlätta framtida omskrivningar separera dessa. På det sättet kan du lägga till extrafunktioner till olika kunder, detta för fler speciallösningar. För att smidigt kunna lägga till funktioner till alla databaser skapar du ett script som uppdaterar alla databaser med samma info..

fråga gärna på icq också - 3417215

/glemme

Vad är det egentligen kunden vill ha? Vill han verkligen ha möjligheten att ha flera exakt likadana webbshoppar? Det låter lite tråkigt... Med tanke på att de flesta affärer ser tämligen olika ut så låter det dumt att låta dem dela på databastabellerna. En cd-affär har ju inte direkt samma krav som en bygg-firma på vad som ska sparas i databasen eller hur saker och ting ska vara relaterade. För att ta ett exempel så kanske en cd-affär vill att man ska kunna betygsätta produkter vilket en byggaffär sannolikt inte vill osv.

Jag föreslår att du talar mer med kunden och dennes exakta behov.

Och så beror det på belastning och prestandakrav. Om ni räknar med att ha hundratals samtidiga besökare så kanske allt måste köras på flera servrar ändå och då är ju det ganska meningslöst med den delade databasen.

1
Bevaka tråden