I teorin låter det inte så dumt tycker jag! Vad tycker ni?
Fakta:
Ett tiotal shoppar med ca. 5000 produkter var.
Varje shop har också kanske ca. 5000 kunder.
Detta ska ju inte vara något problem att köra i en och samma sql 2005 databas.
Till detta tänkte jag använda .net 2.0:s membershipprovider och ange unika ApplicationName:s för varje shop.
Men efter en heldags googlande så blir jag mer och mer osäker på om det är en bra idé, så jag vänder mig helt enkelt till "riktig" expertis för att få svar, dvs. wF! :)
Är det dumt att lägga flera shoppar i samma databas?
Nån som har några erfarenheter om detta?
(det jag bla. kört fast på nu är hur man får ut vilken provider som ska användas då administrationssidorna till shopparna ska ligga på samma domän, dvs. alla butikadmins kommer att logga in på samma ställe)
Generellt så skall du inte göra så, eftersom du då inte skiljer på datan mellan de olika butikerna, du får alltså inte den dataintrigitet som du bör ha.
Dessutom så är det alltid så att du kommer få olika krav på de olika butikerna efter ett tag och om du då implementerar ett krav till en butik som kräver att du ändrar lite i databasdesignen, så kan det göra så att du 1) måste implementera det till de andra 2) göra så att krav från andra butiker inte går att implementera.
Jag hade skapat olika databaser för respektive butik då det kommer att underlätta för dig i framtiden när de olika kraven för de olika butikerna kommer växa fram.
Angående inloggningen så använder jag inte .NET's memberprovider, så jag kan inte hjälpa dig med det, men det jag hade gjort var att om du nu skall ha samma adminsida för varje butik (vilket man ju vill, men som kanske inte är möjligt med tanke på de olika kraven som kommer) så hade jag helt enkelt sparat ner användar information tillsammans med namnet på databasen i en databas och hämtat upp databasnamnet för den användare som är inloggad därifrån, och så satt connectionstring med hjälp av det databasnamnet och vips så kopplar du dig mot de olika databaserna beroende på vem som loggar in.
Som vanligt, väldigt utförligt svarat Gladh! :bire
Jag har svårt att bestämma mig på vilken variant jag ska satsa på, får nog sova på saken! :)
För med de erfarenheter jag har så finns det inte något(?) som en butik har användning av men som en annan inte har. Missförstå mig rätt, det är klart att butiker har olika behov men ta windows tex. Det finns hur många funktioner som helst men man anväder bara de man behöver.
Det talar för en databas.
Å andra sidan, så länge databaserna är exakt lika så går det ju fortfarande att använda samma admin och styra inloggningen som du beskriver.
Hmm, ja, jag får ta en ordentlig funderare på detta! :)
Det är nog inga problem med att göra som du föreslår.
Jag m,enar kapacitetsmässigt är det absolut inga problem
Men Varför vill du göra detta. Vad vinner du. För kunderna kan det nog kvitta.
Men vad händer om en kund vill flytta sina data. Om SQL rasar av någon anledning?
Backup, nyutveckling osv. Jag ser inga skäl till att slå samman om du inte tror att att licenskostnaden för SQL2005 är avgörande. Men det går väl att lösa med upplägg i olika tabeller.
I min värld så fungerar det så här:
Nästan ingen av våra kunder kommer själv med egna ideér om vad som behöver utvecklas utan det är jag (eller vi på företaget) som presenterar nya funktioner som skulle kunna finnas i butiken.
I och med det så kan vi också styra funktionerna så att de passar våra andra kunder också och därmed tjäna mer pengar snabbare!
Och har man då en och samma databas så är det ju en baggis att bygga in nån sorts aktiveringsfunktion som man slår på om en kund vill ha "uppgraderingen" och sen skicka en fet faktura utan att behöva lyfta ett finger, typ! :)
Det är en av vinsterna.
En annan är att underhållet blir mycket enklare. Om man hittar en bugg t.ex. i systemet som beror på databasen så är det bara på ett ställe man behöver justera så slår det igenom på alla butiker, annars lär man in på alla databaser och upprepa samma procedur och är då vissa butiker kundanpassade så är det inte säkert att man vågar gå in och ändrada den databasen på samma sätt.
Jag tycker kundanpassningar är bra (för det finns mycket pengar att tjärna där) MEN om kundanpassningen går att sälja till fler än en så är det ännu bättre! :bire
Jag håller med dig doggelito, att göra en massa anpassningar till enskilda kunder kanske ger konsultpengar på kort sikt men risken finns ju att man målar in sig i ett hörn med en massa olika applikationer som måste utvecklas var och en för sig. Supporten blir krångligare. Då är det väl mycket bättre att sälja en produkt och göra eventuella anpassningar valbara.
Nu har jag bestämt mig!
Det får bli unika databaser för butikerna men med ett gemensamt admin.
Och för att komma till rätt databas så löser jag det på det sättet som Gladh föreslog, en databas där connectionsträngar hämtas.
Sen gäller det bara att vara supernoga med att om en ny modul byggs på så måste samtliga databaser uppdateras. Men jag tror det är värt mödan! :)
För att hålla koll på databaserna är det ju bara att ha ett enkelt excel ark där varje kund listas och var de ligger i databasförändringarna. För varje ny struktur/data som ska in i db:n är det bara att lägga till en ny punkt i arket.
och inte behöver man ha olika applikationer till de olika kunderna bara för de har olika anpassningar. Detta kan du styra med kundnamn i database och när du gör anpassningarna är det bara att kolla vilken kund det är till.
Är det anpassningar som du tror kan bli generella är det ju bara att sätta en flagga i config eller i db som säger om den ska visas för respektive kund eller ej.
266 ms totalt · 4 externa anrop · v20260731065814-full.a51de22e
