[Alg] Systeem met 2 db's & real-time updated

[Verwijderd]

Ik heb deze vraag al gedeeltelijk in een ander topic gezet. Alleen het ging daar een beetje door elkaar heen lopen, vandaar een eigen topic.


Ik wil een verkoop systeem gaan maken met daaraan vast gekoppeld een websysteem (waarvan de informatie ook real-time bijwerkt dient te worden) waar de gebruiker producten online kan bestellen.

Het verkoop systeem zal bestaan uit een windows applicatie (gemaakt in Delphi) waarbij je facturen kan maken, voorraad wijzigingen, enz... (dus een soort kassa systeem). Deze applicatie zal gebruik maken van een postgresql database. Ook moet deze applicatie dingen als producten, categorieen, enz.. beheren voor zowel de website als de applicatie zelf.

Het websysteem zal gemaakt worden in PHP en maakt ook gebruik van een postgresql database.

Deze 2 systemen maken is geen probleem. Het gaat om de koppeling er tussen.

Nu dacht ik om die db online te gooien bij een hosting bedrijf en dan zal dus zowel de website als de windows applicatie daar gebruik van kunnen maken. Maar dit heeft 1 groot nadeel: wat te doen als de internetverbinding er uit legt. Dan kan je dus geen verkopen registreren, enz... Ook kan je in de winkel geen product gegevens opvragen omdat die allemaal in die db die online staat zich bevinden.

Oftewel dat is dus geen goede methode. Na het een en ander gelezen en gehoord te hebben ben ik er achter gekomen dat er misschien gebruik gemaakt moet worden van replication. Ik heb hier zelf totaal geen ervaring mee en weet dus niet of dit wel goed gaat.

Bij die synchronisatie is er 2 richtingsverkeer. Zo moeten de gegevens over bijv de producten naar website database gestuurd worden en moeten de bestellingen via de website naar de winkel database gestuurd worden.

Een ander idee van iemand was om batch-files te gaan werken ipv replication. Maar wat dat precies inhoud weet ik niet.

Wat vinden jullie de beste keuze? Ook is het belangrijk om te kijken naar de db keuze. Ik wil zoiezo met php gaan werken en omdat veel hosting bedrijven ondersteuning bieden voor postgresql is mijn keuze daarop gevallen. En ook een belangrijke vraag is of postgresql wel echt goed geschikt is voor dat replication verhaal als dat de methode zou zijn die gebruikt moet gaan worden.

[BierPul]

Ik weet wel dat MySQL een redelijke replicatie functie heeft maar das volgens mij alleen van Matser naar Slave db

Je wilt eigenlijk 2db's hebben die continu van elkaar op de hoogte zijn maar dat redt je in principe al niet als er 1 van de db's wegvalt dan heb je natuurlijk de kans op duplicate keys etc

Misschien kan je iets verzinnen zonder een autoincrement veld waarin je in de ene db alleen maar transacties opslaat met een even id en de andere een oneven dan kan je ze zonder problemen samenvoegen eens in de zoveel tijd

Dat lost natuurlijk nog niet je probleem op met vooraad wijzigingen etc maar daar is vast wel wat op te verzinnen

[ Voor 88% gewijzigd door BierPul op 13-09-2003 00:20 ]

[farlane]

Lokale kopien bijhouden misschien. Beetje on - economisch maar volgens mij moet je wel. Je moet toch altijd een soort offline db hebben om nog te kunnen verkopen als er iets mis is met het netwerk.

[Skinkie]

eigenlijk zou je een soort migratie db er tussen moeten gooien dat direct (indien mogenlijk) of om het uur beide databases van updates voorziet. Je zou hiervoor een slimme stored procedure kunnen maken die op basis van een aantal unieke velden (zoals een timestamp bijvoorbeeld) gaat controleren of er migraties gedaan moeten worden

je bent er dan in iedergeval zeker van dat het online en offline, met een periode van hooguit je downtime goed komt

[Verwijderd]

PeerDirect ondersteund geloof ik postgressSql, dit is een pakket voor database replicatie.
Werkt prima, is alleen beetje prijzig.
Om twee databases te koppelen ben je zo'n € 26000,- kwijt (aanschaf), komt nog wat implementatie bij, wat ondersteuning etc.
Voordeel is wel je kan heel gemakkelijk meerdere databases koppelen, en of je nu uurtje offline bent of niet, replicatie gaat goed daarna.
Voor problemen met Duplicate keys voorzien ze in een oplossing, evenals voor problemen met zogenaamde 'update-collisions'.

[ Voor 3% gewijzigd door Verwijderd op 13-09-2003 02:59 ]

[djluc]

Je krijgt echt problemen hiermee als je een actief voorraadbeheer gaat doen. Stel je voor dat er nog 1 product x is, een klant in de winkel koopt een product. Nog voor de volgende update koopt een internetklant hetzelfde product. Je hebt nu 2 producten verkocht terwijl er maar 1 is, dat is niet zo prettig lijkt mij.

Ik zou gaan voor het volgende idee: je actuele db is altijd de lokale db. Indien er een internetconnectie is worden daar alle gegevens uit gehaald door de webserver. De website haalt de gegevens alleen maar uit de lokale db, dus in de winkel. Zodra de internetconnectie weg valt gaat de website de db op de webserver gebruiken, bestellen is dan echter niet mogelijk. Dat kun je wel implementeren, gewoon vanuit PHP een soort van ping sturen of een file proberen te openen.

[slm]

Ik ga voor 99% met djluc mee in dit verhaal, maar imho moet het altijd mogelijk zijn om bestellingen te doen met disclaimer.

Daarnaast zou je de volgende situatie kunnen creëren:
lokaal: actieve db met voorraadbeheer
internet: dagelijkse/wekelijkse kopie van assortiment zonder voorraadbeheer.

Wanneer de connectie wegvalt van de internet server naar je lokale server, pak je idd de database op de internet server, met dien verstande dat je er bij zet dat voorraden op dat moment niet gecontroleerd kunnen worden, excuses voor het ongemak blah, etc. Op die manier voorkom je een zeer kostbare / tijdrovende / datatraffic-hogging / intensieve realtime kopieeractie via wat voor manier dan ook (replicatie, xml, batch etc).

[Verwijderd]

Artikelen is idd niet zo moeilijk die kan je dagelijks syncen (dus omschrijvingen etc).
Je voorraad zou je met lokatie's bij kunnen gaan houden,
Winkel is locatie A, Web is locatie B, zo kan je een bepaalde voorraad toewijzen
aan locatie's, en een bepaalde prioriteit met minimum aantallen in voorraad per
locatie. Het ene product zal waarschijnlijk meer in de winkel verkopen dan op het
web en vice versa.

Eens in de x tijd controleer je de minimum voorraden, en is er op 1 lokatie een te kort
dan kan je met een simpele vergelijking kijken of je producten van lokatie A moet overhevelen naar lokatie B of omgekeerd.

Voor noodgevallen kan je dan met een manuele ingreep hier op ingrijpen om naast het automatisch syncen/overboeken artikelen van de ene naar de andere locatie over te boeken.

Hiervoor ga je wat meer moeten bijhouden dan het simpele 1 produkt binnen (inboeken), 1 produkt verkocht (afboeken). Je zal dan met omzet snelheden moeten gaan werken e.d. (ook weer per lokatie),
maar op deze manier krijg je denk ik altijd de juiste voorraden per lokatie en kunnen de
databases vrijwel onafhankelijk van elkaar werken (naast de sync actie eens in de zoveel tijd).

[edit]
Het is trouwens wel een zeer interessante probleem stelling dit.

[ Voor 15% gewijzigd door Verwijderd op 13-09-2003 12:06 ]

[djluc]

slm schreef op 13 September 2003 @ 11:50:
Ik ga voor 99% met djluc mee in dit verhaal, maar imho moet het altijd mogelijk zijn om bestellingen te doen met disclaimer.

Ik zou nooit bestellingen voorwaardelijk door gaan voeren. Ik zou de gegevens, de productnummer oid die de klant besteld heeft gewoon bewaren. Zodra de Internet link weer up is stuur je een mailtje met daarin een link waarmee ze alsnog kunnen bestellen. Hier staat ook meteen welke producten dan niet meer verkrijgbaar zijn.

Over het aantal en de periode tussen het synchroniseren is niets te zeggen zonder meer informatie over het aantal inserts/verkopen en de periode daar tussen.

Verwijderd schreef op 13 september 2003 @ 12:00:
Eens in de x tijd controleer je de minimum voorraden, en is er op 1 lokatie een te kort
dan kan je met een simpele vergelijking kijken of je producten van lokatie A moet overhevelen naar lokatie B of omgekeerd.

Je kunt dan niet het actuele aantal producten laten zien. Verder kan het gebeuren dat iemand een groot aantal van dezelfde items wil gaan kopen. Dan is het mogelijk dat je die niet meer op B hebt terwijl er nog wel in A liggen->de gebruiker gaat naar een andere site en koopt het product daar.

Ik blijf bij het idee in mijn vorige posts, want het is niet zo dat die internet verbinding er dagelijks uit valt. Daarom zou ik de voordelen van het werken in een actuele DB boven de mogelijke downtime, eigenlijk bestel-down-time, zetten.

[ Voor 55% gewijzigd door djluc op 13-09-2003 12:07 ]

[Verwijderd]

djluc schreef op 13 September 2003 @ 12:02:
[...]
Je kunt dan niet het actuele aantal producten laten zien. Verder kan het gebeuren dat iemand een groot aantal van dezelfde items wil gaan kopen. Dan is het mogelijk dat je die niet meer op B hebt terwijl er nog wel in A liggen->de gebruiker gaat naar een andere site en koopt het product daar.

Is een goed punt.
Maar dan kan je weer met je min. voorraad spelen, dit soort producten zullen dan wel vaker in grotere aantallen besteld worden, dus zet je je min. voorraad voor lokatie B wat hoger. Maar dat garandeerd idd niet dat je altijd de min. voorraad zal laten zien wat sommige mensen willen gaan bestellen, hmz ff denken.....

[slm]

djluc schreef op 13 September 2003 @ 12:02:
[...]Ik zou nooit bestellingen voorwaardelijk door gaan voeren. Ik zou de gegevens, de productnummer oid die de klant besteld heeft gewoon bewaren. Zodra de Internet link weer up is stuur je een mailtje met daarin een link waarmee ze alsnog kunnen bestellen. Hier staat ook meteen welke producten dan niet meer verkrijgbaar zijn. [...]

Dat ligt er maar aan wat de klant verwacht / eist. Bovendien werkt het FIFO systeem niet meer. Klanten die eerst hebben besteld, kunnen op een later moment hun email lezen dan klanten die later hebben besteld. Vrij oneerlijk dus.

[...]Je kunt dan niet het actuele aantal producten laten zien.

Ligt dus aan wat de klant verwacht / eist of dat wel of niet onredelijk is.

Verder kan het gebeuren dat iemand een groot aantal van dezelfde items wil gaan kopen. Dan is het mogelijk dat je die niet meer op B hebt terwijl er nog wel in A liggen->de gebruiker gaat naar een andere site en koopt het product daar.[...]

Precies dus een reden volgens mij om wél bestellingen te laten plaatsvinden

[Verwijderd]

Even los van de verschillende methoden om het probleem op te lossen.

Het ligt natuurlijk geheel aan de aard v/d winkel (en bijbehorende producten), of het wel
in de verwachting van klanten ligt dat hele grote aantallen, direct geleverd kunnen worden.
Ik denk dat als er grote aantallen van iets besteld worden, de klant er wel vanuit gaat dat dit apart besteld moet worden door de winkel of in ieder geval niet direct leverbaar is uit
de actuele voorraad.

Je moet op het web dan ook niet de preciese voorraad weergeven, maar in indicatie van hoe snel een product geleverd kan worden.

[djluc]

slm schreef op 13 September 2003 @ 12:20:
Dat ligt er maar aan wat de klant verwacht / eist. Bovendien werkt het FIFO systeem niet meer. Klanten die eerst hebben besteld, kunnen op een later moment hun email lezen dan klanten die later hebben besteld. Vrij oneerlijk dus.

Dat ligt er maar helemaal aan hoe je het implementeerd, als je bijvoorbeeld reserveringen aanmaakt dan voldoe je wel aan FIFO. Het gaat er dan ook maar net om wat de klant wil.

[...]
Precies dus een reden volgens mij om wél bestellingen te laten plaatsvinden

Nee, want de aanvraag staat al wel in je database, dit geef je natuurlijk door aan de klant. Verder krijgen ze een mailtje, wat voor de klant de indruk wekt, als je het goed brengt natuurlijk, dat ze al besteld hebben. Je zou het zelfs kunnen combineren met een bevestigingsmailtje dat je toch al naar alle klanten gaat sturen als ze iets bestellen.

Verwijderd schreef op 13 september 2003 @ 12:28:
Even los van de verschillende methoden om het probleem op te lossen.
[...]Je moet op het web dan ook niet de preciese voorraad weergeven, maar in indicatie van hoe snel een product geleverd kan worden.

Dat is ook maar net wat je als bedrijf wilt. Het kan zijn dat het handgemaakte producten zijn, die allemaal uniek zijn, dan wil je dus wel het exacte aantal hebben. Als je het systeem zo maakt dat het aan beide mogelijkheden kan voldoen heb je een systeem wat je voor meerdere klanten kan gebruiken. Daar zou ik voor gaan.

Overigens is het voorspellen van de levertijd wel een leuke uitdaging, je zou zelfs links kunnen maken met gegevens van leveranciers over levertijden. Als ze een site hebben zou je zelf een hele goede voorspelling kunnen doen. Het blijft steeds hetzelfde, de klant is koning.

[ Voor 29% gewijzigd door djluc op 13-09-2003 12:37 ]

[slm]

Je kan beide methodes enigszins combineren. Mailtje sturen met bevestiging, opmerking voorraad niet oproepbaar en dat het pas werkelijk doorgevoerd zal worden als het systeem weer online is, link om bestelling te annuleren. Als klant niets doet, wordt de bestelling automatisch FIFO geplaatst. Degenen die vervolgens buiten de boot zijn gevallen, krijgen mailtje met evt alternatieven.

[Verwijderd]

Het is trouwens ingewikkelde materie.

djluc schreef op 13 September 2003 @ 11:00:
Ik zou gaan voor het volgende idee: je actuele db is altijd de lokale db. Indien er een internetconnectie is worden daar alle gegevens uit gehaald door de webserver. De website haalt de gegevens alleen maar uit de lokale db, dus in de winkel. Zodra de internetconnectie weg valt gaat de website de db op de webserver gebruiken, bestellen is dan echter niet mogelijk. Dat kun je wel implementeren, gewoon vanuit PHP een soort van ping sturen of een file proberen te openen.

Maar dat is toch niet echt een goede methode. Je gaat dan de website laten connecten naar je eigen internetverbinding wat niet echt een snelle verbinding is. Dat is namelijk ook de rede dat je het overlaat aan een hosting bedrijf.

Maar over dat voorraadbeheer, op zich vind ik dat nog niet echt het belangrijkste. Dat zou er van mij wel uit mogen blijven. (Dus dat men op de website ziet of het artikel op voorraad is).

Maar ik ben toch benieuwd hoe bijv Informatique het systeem ontworpen heeft, want die heeft namelijk ook een real-time systeem. Kijk als je zelf zou gaan hosten is er niks aan de hand, maar ik kan me niet voorstellen dat iemand en zeker informatique dat zou doen.

[djluc]

Verwijderd schreef op 13 September 2003 @ 12:49:
Maar dat is toch niet echt een goede methode. Je gaat dan de website laten connecten naar je eigen internetverbinding wat niet echt een snelle verbinding is. Dat is namelijk ook de rede dat je het overlaat aan een hosting bedrijf.

Je startpost ging over het feit dat de link weg kon vallen en dat je niet wilt dat je site dan helemaal down is. Verder zou ik alleen de db lokaal zetten, dus de rest van de website bij de hoster. Alleen data is opzicht niet zo heel veel dataverkeer. Ook het CMS en wat je nog meer hebt zou ik bij de hoster zetten.

Maar over dat voorraadbeheer, op zich vind ik dat nog niet echt het belangrijkste. Dat zou er van mij wel uit mogen blijven. (Dus dat men op de website ziet of het artikel op voorraad is).

uit je startpost:

Ik wil een verkoop systeem gaan maken met daaraan vast gekoppeld een websysteem (waarvan de informatie ook real-time bijwerkt dient te worden) waar de gebruiker producten online kan bestellen.

Wat versta jij hier dan onder? Verder is het niet fijn als mensen producten gaan bestellen die er helemaal niet zijn.

[Brothar]

Informatique zou best wel eens kunnen werken volgens het systeem vam maui71.
(Zat ik dus ook aan te denken).

[ Voor 134% gewijzigd door Brothar op 13-09-2003 13:34 ]

[Verwijderd]

djluc schreef op 13 September 2003 @ 12:55:
Je startpost ging over het feit dat de link weg kon vallen en dat je niet wilt dat je site dan helemaal down is. Verder zou ik alleen de db lokaal zetten, dus de rest van de website bij de hoster. Alleen data is opzicht niet zo heel veel dataverkeer. Ook het CMS en wat je nog meer hebt zou ik bij de hoster zetten.

Daar bedoelde ik dat als je maar 1 db gaat gebruiken en die online gooit. Dat zou betekenen dat alles niet meer te gebruiken is, zowel winkel als web.
Daarom denk ik ook dat je met 2 db's moet gaan werken.

Trouwens ik wil ook niet echt met een CMS gaan werken. Die taak zal door de windows applicatie verricht worden.

Wat versta jij hier dan onder? Verder is het niet fijn als mensen producten gaan bestellen die er helemaal niet zijn.

Wat ik eigenlijk wil is dat wanneer de producten, prijzen veranderd worden in de winkel (dus via de windows app) deze ook direct op de website te vinden zijn. Kijk het voorraad gebeuren zou leuk zijn als dat er bij zou zitten, maar dan heb je met nog veel meer ingewikkelde zaken te maken. Op zich is dat niet echt meer een vereiste (na alle problemen gelezen te hebben).

[djluc]

Verwijderd schreef op 13 September 2003 @ 13:06:
[...]
Daar bedoelde ik dat als je maar 1 db gaat gebruiken en die online gooit. Dat zou betekenen dat alles niet meer te gebruiken is, zowel winkel als web.
Daarom denk ik ook dat je met 2 db's moet gaan werken.
Trouwens ik wil ook niet echt met een CMS gaan werken. Die taak zal door de windows applicatie verricht worden.

Dat heb je in mijn voorbeeld toch ook, het enige verschil is dat je geen dingen koopt in de internet database, dit omdat je nooit zeker bent of de spullen er nog zijn.

Wat ik eigenlijk wil is dat wanneer de producten, prijzen veranderd worden in de winkel (dus via de windows app) deze ook direct op de website te vinden zijn. Kijk het voorraad gebeuren zou leuk zijn als dat er bij zou zitten, maar dan heb je met nog veel meer ingewikkelde zaken te maken. Op zich is dat niet echt meer een vereiste (na alle problemen gelezen te hebben).

Je wilt het wel of niet, je manier van denken neem ik een beetje in twijfel. Een aantal mensen posten hier dat het lastig kan gaan worden, dus dan maar niet. Ik neem aan dat je voor een project als deze al een plan van eisen hebt. Daarin staat als je het goed hebt gedaan precies wat je wilt maken.

[Verwijderd]

djluc schreef op 13 september 2003 @ 14:58:
Dat heb je in mijn voorbeeld toch ook, het enige verschil is dat je geen dingen koopt in de internet database, dit omdat je nooit zeker bent of de spullen er nog zijn.

Ik snap niet wat je bedoeld met "geen dingen koopt in de internet database". Kan je dat nog even verduidelijken.

Je wilt het wel of niet, je manier van denken neem ik een beetje in twijfel. Een aantal mensen posten hier dat het lastig kan gaan worden, dus dan maar niet. Ik neem aan dat je voor een project als deze al een plan van eisen hebt. Daarin staat als je het goed hebt gedaan precies wat je wilt maken.

Ik zit nog in het aller eerste stadium. Ik ben eerst aan het kijken wat wel en wat niet mogelijk is met de middelen en kennis die ik op dit moment heb. Aangezien het om een winkel gaat die in eerste instantie nog weinig op voorraad zal hebben, is de voorraad indicatie nog niet echt belangrijk. (Het is namelijk niet echt goed als de klant overal ziet: is niet op voorraad).

[djluc]

Verwijderd schreef op 13 september 2003 @ 17:00:
[...]
Ik snap niet wat je bedoeld met "geen dingen koopt in de internet database". Kan je dat nog even verduidelijken.

Als je internetverbinding weg is maak je gebruik van de database bij je hoster, anders je lokale db. Wat je natuurlijk wel kunt doen is verkopen in de internetdb, en daarna gaan synchroniseren. Als er geen conflicten zijn is het ok, maar als er wel conflicten zijn zul je bepaalde mensen teleur moeten stellen.

[...]Ik zit nog in het aller eerste stadium. Ik ben eerst aan het kijken wat wel en wat niet mogelijk is met de middelen en kennis die ik op dit moment heb. Aangezien het om een winkel gaat die in eerste instantie nog weinig op voorraad zal hebben, is de voorraad indicatie nog niet echt belangrijk. (Het is namelijk niet echt goed als de klant overal ziet: is niet op voorraad).

Ik zou altijd beginnen met een overzicht van de wensen en eisen. Dan weet je tenminste waar je over praat. Dan weet je ook meteen of je een real-time db verbinding nodig hebt, of dat het ook in een tijdelijke db die geupdate wordt kan.

Verder moeten we wel stellen dat een ADSL verbinding in Nederland, zeker als je een zakelijk pakket neemt niet zomaar uit zou vallen. En mocht het een keer uit vallen zal het geen langdurige storing zijn.