Om man har en webshop där alla artiklar ligger i en databas som dessutom sparar vad kunden handlat tidigare etc så vill man ju ha dessa uppgifter kvar så man kan föra statistik o sånt..
Så långt är ni med va? :)
Men om den som äger själva webshopen själv sitter offline med en kopia på databasen och gör prisjusteringar, lägger till & tar bort artiklar & sedan skickar upp den uppdaterade databasen till webbservern så ersätter man ju den databasen som ligger servern & innehåller värdefull data om kunderna. Det är ju inte så lyckat ;)
Därför undrar jag om det på nått enkelt vis går att fixa en funktion som automatiskt sparar den gamla databasen med ett annan namn varje gång man skickar upp en ny?
Ett annat alternativ vore ju iofs att spara alla kunduppgifter i en separat databas, men det har väl sina nackdelar i att själva shopen blir slöare med tanke på flera databasanrop etc?
Man kanske kan göra ett script som överför all data till en annan databas INNAN man skickar upp den nya? Ett klick på en länk nånstans i det adminsystem som redan finns?
Kan man helt enkelt låta ett script köras varje gång ett köp genomförs som "kopierar" databasen?
Eller tar det för mycket kraft på servern?
Vad jag är ute efter primärt är lite tips o råd på hur man BÖR göra för att alltid försäkra sig om att tidigare inköp etc sparas på ett vettigt sätt.
Databasen innehåller följande tabeller:
PRODUKTKATEGORIER - Uppdateras sällan.
PRODUKTER - Här ligger all fakta om produkterna & är en tabell som uppdateras varje vecka typ.
VARUKORG - Lagrar vad kunden köpt vid varje tillfälle.
Det enklaste är att du inte uppdatera hela databasen utan endast PRODUKTER-tabellen varje vecka.
Dumpa kundens uppdaterade PRODUKT-tabell till en exportfil och importera i databasen, på så sätt behåller du all annan info.
Ett problem dock, jag antar att VARUKORG har främmande nycklar till produkter i PRODUKT. Om gamla produkter tas bort och/eller ändras avseende t.ex pris så kommer historiken att fuckas upp, om t.ex Olle köper en stekspade för 21.50 den 3 mars och sen uppdateras stekspade-produkten till priset 55.50 så kommer statistiken för Olle att vara felaktig..
------------------ "To iterate is human, to recurse, divine" - L. Peter Deutch
Prisinfon är ovesäntlig i just detta fall sgtpepper, men bra att du tar upp det för framtida bruk!
Har du lust att utveckla lite mera ingående hur du menar med att dumpa tabellen till en exportfil och uppdatera med den? Jag fattar inte ett smack om sånt ;)
Är det en funktion i ASP du menar eller är det nått man måste göra i Access?
Låter som ett invecklat problem tycker jag. Alltid bökigt med offline-databaser som skall synkas mot master-databaser.
Det absolut bästa är nog att jobba mot samma databas, dvs. inte offline.
Det näst bästa är att hålla reda på ändringarna man gör offline för att sedan föra över dom till master-databasen. För att åstadkomma det kan det behövas ett specialprogram som håller reda på vad användarna ändrar, ex. priser, kunder.
Eventuellt att läsa i databasens loggfil.
Man sparar oftast mycket trafik på att bara föra över ändringarna i stället för att kopiera hela databasen. Är det ett kund-/artikel-/priser-/statistik-register kan det ju bli många poster.
Har själv utvecklat sådana system och då har man varit tvungen att ha med detta i tankarna redan från första början. Kan påverka databasens struktur och dylikt.
En lösning kan vara att ha en egen databas med sådant som inte ändras från webben, dvs. bara ändras av ägaren.
Eller att isolera denna informationen i egna tabeller som sedan kan kopieras över från motsvarande tabeller från offline-databasen.
Dvs. man försöker dela databasen i två delar.
Kanske inte går att genomföra på ett befintligt system men men.
Men det bästa vore alltså att separera det som "shopinnehavaren" vill uppdatera från det som uppdateras i samband med köp på nätet i skilda databaser?
Kanske inte det bästa alternativet men det enklaste om man vill kunna byta ut hela databasfilen.
Det går att skapa sql-er som joinar mellan flera databaser. Om det sedan blir långsammare vet jag inte. Kanske finns det andra fällor som jag inte ser.
Jag hade nog inte själv löst det så här men det är trots allt en lösning som borde fungera.
För enkelhetens skull gentemot min kund som inte är alltför bevandrad i datorer etc så skulle jag vilja ersätta hela databasen vid varje uppdatering. Men jag är givetvis öppen för andra förslag om det inte blir på bekostnad av prestandan...
En importfunktion för nya/ändrade produkter (inkl priser).
Sedan behövs det en funktion för att generera en sådan importfil.
Filen kan laddas upp till webbhotellet för att sedan läsas in i databasen med ett script. Filen hade jag gjort i XML. Ger en flexibel lösning där det går lätt att lägga till ny information som skall importeras.
Om du i databasen har datum kolumner för att hålla reda på när artiklar/priser ändras går det att göra ett script som genererar importfilen automatiskt. Låt säga att master-databasen har uppdateringar från förra veckan. Då kan man be offline-databasen generera en importfil med ny/ändrade artiklar och priser från och med förra veckan.
Scriptet måste klara av att läsa in samma information två gånger för att förhindra strul vid avbrutna importer och dyligt.
Hmmm, jag tycker absolut inte att de gamla priserna/prislistorna skall raderas. Den informationen är mycket värdefull i kombination med den övriga informationen i databasen. All prishistorik skall sparas. T ex kanske din kund vill se hur försäljningsvolymerna ändras när priset sänks. Jag hörde VD:n för Bidlet (OK för att de inte är så hippa idag)snacka om att de hade två heltidsanställda som bara satt och analyserade sådan här pris- och budinformation.
[Redigerat av clarkbones den 05 sep 2001]
258 ms totalt · 4 externa anrop · v20260731065814-full.1dc6f849
