Jag sitter och specar på ett kassasystem. Och som med alla andra verksamheter så skall man kunna sälja saker även om servern/linan går ner och man inte får tag i den data som man behöver ;) Jag var på Microsofts kick-off för VS 2005 för ett par år sedan och där snackade jag med en snubbe som sålde just kassasystem. De hade i a f en central SQL 2005 och sedan en SQL Server Express på den lokala kassapc:n. Kanske kan vara något att ta efter? Om nätverket gick ned så reggades allt i SQL Server Express-db:n. Hur synkningen sedan gick till vet jag inte, skulle gissa på replikering. Tror replikering är relavtivt enkelt ... "på tal om brödrostar" så lär det komma nån funktion i VS2008 som gör cachningen betydligt lättare att implementera, däremot tror jag att det var så att du fortfarande själv måste veta när du ska synka. Jo jag har funderat på SQL Server Express ute i på de olika butikerna, men skulle helst vilja slipa en extra databas, inte för att det är fel, det är säkert helt korrekt och enkelt att lösa, men underhållet för de tekniska bitarna ökar. Jag snubblade över den här länken för ett tag sedan som jag tänkte, den kan vara bra att ha i framtiden. Eftersom den lokala "databasen" är single-user borde det räcka att dumpa till en fil. T.ex. Dataset till XML. Det låter inte fräckt, men det skulle antagligen räcka bra i det här fallet. Tanken är väl att de oftast är online och att synkning från offline är ett undantagsfall? Du slipper då installera nån db hos dem det räcker att de har en hårddisk :) Eventuellt bygger du ett program vid sidan av som bevakar och synkar så att det inte stör online-användningen av systemet. Detta blir mycket enklare, och du löper mindre risk för mystiska buggar än om väljer att implementera en komplex infrastruktur med manuell Tcp-kommunikation, köer, offlinedatabaser, osv. Jag funderar på att hålla viss data ute på klienten. Denna data skall ju användas även när systemet är "online" bara för att få upp prestandan när man bara skall köpa produkten. Då behövs ju "iprincip" endast: Namn, EanCode, Pris (och lite till) för artiklen för att man skall kunna skapa en transaction och skriva ut kvitto till kunden.Aritektur/Design undran!
Jag har sett lite olika lösningar på detta och den lösning som jag tycker verkar mest lovande är att man behandlar systemet som om det alltid var "offline". Alltså alla transaktioner som görs läggs på en kö för vidare behandling av själva servern. Det medför ju lite andra komplikationer med kvittonr och id-nummer osv osv, men det tror jag har löst.
Mitt problem är mer att när systemet verkligen är "offline" så finns det ju massor med information som man inte kan nå längre (och som inte är kritisk heller) medans man har annan information som man måste kunna nå ändå, typ artikelinformation. Om linan går ner så måste ju systemet ändå kunna hitta artikel utifrån EAN-kod och plocka fram rätt pris osv osv medans det kanske inte är livsviktig att kontrollera status på en order för någon kund...
Så om vi tar artiklarna så måste systemt kunna nå dessa även om systemet går "offline". Så då tänkte jag så att om man har en "temporär" lagring av artiklarna någonstans (databas/binarfil/xmlfil), om man sedan lägger denna lista med artiklar i internminnet i en lista så går det hyfsat fort att hämta upp basinformationen om artiklen utifrån EAN-kod, och om systemet är "online" så kan man fråga servern efter övrig information som inte lagras temporärt (typ lagerstatus).
Så nu till själva frågan ;). Hur hade ni löst själva synkroniseringen mellan servern och den "temporära lagring". Jag menar om man ändra priset på varan så vill man ju att den information skall ut till klienterna så fort som möjligt så om systemet går ner 30 sekunder efter man ändrat varans pris, så skall alla kassor kunna hämta det nya priset från sin "temporära lagrings plats".
- Vad hade ni valt för temporär lagringsplats? Databas/fil-systemt?
- Vilken synkroniseringsmekanism hade ni valt? Replikering (databas)/eventbaserad/pollingsfunktion/kösystem?
- Verkar idén bra? Eller skall man lösa det på något annat sätt.
MVH
MagnusSv: Aritektur/Design undran!
Sv: Aritektur/Design undran!
Sen om det här har någon som helst relevans vet jag inte...Sv:Aritektur/Design undran!
Jag tänker bland annat på den SQL mask som härjade för att det stod en massa SQL Express ute på företag som inte hade en anning om att olika program hade installerat en sådan. Man får ju utgå i från att de som har en butik, inte kommer vara de bästa på att uppgraderar och underhålla sina kassor. De skall ju bara fungera ;)
Så kan man lösa det på något annat sätt så vore det perfekt...
- MSv: Aritektur/Design undran!
http://www.marcclifton.com/Default.aspx?tabid=147Sv: Aritektur/Design undran!
"good, fast, cheap: choose two"Sv:Aritektur/Design undran!
När en transaction görs så läggs den på en kö som skickar den till servern, alltid. Jag bryr mig alltså inte om om systemet är online eller offline när transaktionen görs, det görs alltid på samma sätt (mindre kod = mindre buggar).
Så då återstår ju uppdateringen av min clientdata när någon ändrar i informationen. Jag tror nog jag väljer att låta servern pusha ut förändringarn till klienterna i något kö system. Så att klienten har en tråd i bakgrunden som ligger och väntar på information och uppdaterar sedan datan som ligger på klienten. Lite multithreading är ju alltid roligt att programmera.
Någon kommentar???
- M