Koppelen + uitlezen MySQL en andere type databases
Rob Doemaarwat op 20/04/2019 19:06:24:
want dan heb je geen gedoe met punt *of* komma
Klopt, totdat je met precizies gaat werken, volgens mij kwam dat in een andere draadje voorbij.
Casper Richelle op 20/04/2019 19:46:23:
De bedoeling zal wel zijn om synchroon te werk te gaan. Dit om de voorraden zo up-to-date mogelijk te houden.
Mja, maar dan ben je nog steeds afhankelijk van de werkwijze van deze partijen en die zullen dit (directe updates) dan moeten ondersteunen, tenzij je dus een dikke vinger in de pap hebt zoals @Rob aangaf en je zelf gaat voorschrijven hoe en wanneer je informatie wilt.
Ook ben ik benieuwd wat je hier mee wilt gaan doen? Want dit (een soort van vergelijkingssite) is niet echt meer een noviteit.
Het wordt geen vergelijkingssite zoals deze nu bestaan, dit is inderdaad niet vernieuwd.
Om het kort door de bocht te zeggen (helaas kan ik het niet in detail uitleggen) wordt het een matchmaker voor de e-commerce/m-commerce. De consument moet weer bij de beste deal kunnen komen, iets wat nu zeker nog niet het geval is.
Zou een REST API vanuit mijn kant helpen om te zorgen voor een koppeling voor doorlopende updates wanneer er een wijziging in de voorraad is?
Alle informatie die jullie in de afgelopen posts ga ik voor mezelf even overzichtelijk maken zodat ik ik beeld krijg aan welke dingen ik moet gaan denken.
Met vriendelijke groet,
Casper
Met andere woorden: Kijk eens per aanbieder eens wat hun mogelijkheden zijn. Als je dat weet, dan kan je per stuk een importeer-script maken.
Gewijzigd op 21/04/2019 00:28:35 door - Ariën -
Neem eens contact met hun op, of spit eens door hun documentatie. Elke site kan het weer anders aanbieden.
Toevoeging op 21/04/2019 19:51:24:
Wat betreft het PUSH-mechanisme, op google kom ik vrij veel verschillende dingen tegen en door mijn gebrek aan kennis op dit gebied weet ik niet precies wat dit inhoud. Is er een PUSH-mechanisme aan te raden?
PULL: jij moet het bij de andere partij ophalen (binnentrekken = pull).
PUSH is meestal aan te bevelen, omdat je dan direct een berichtje krijgt als de ander wat te melden heeft (en daar niet zelf constant om hoeft te vragen). Moet die andere uiteraard wel een beetje real-time PUSH-en (en niet volgens een vast schema).
Dit zijn echter heel algemene kreten. Dat kun je dan nog op 100 verschillende manieren uitvoeren (het is niet vorm vast). Dus wederom "een soort API op basis van REST/SOAP/whatever".
Bij eventuele vragen/adviezen kom ik graag terug voor jullie expertise!
Met vriendelijke groet,
Casper
Vervolgens wanneer je al deze data hebt in je MySQL (of gelijk welke relationele database je neemt), kan je deze doorzoeken. Mocht je willen werken met een snelle zoekengine of wanneer je echt heel veel data hebt raad ik je wel aan om een NoSQL database te nemen voor je search. Deze data dien je dan wel periodiek up te daten naar wat je in je relationele database hebt.
Het is inderdaad de bedoeling dat de request niet vetraagt wordt door de hoeveelheid data, althans zo min mogelijk vertraging.
Met welke frequentie zal er een API call gedaan kunnen worden? Het is namelijk van belang dat wanneer er een zoekopdracht gedaan wordt op het platform de info up to date is. Er zal een beta gerund worden met 20-30 shops om te kijken hoe het systeem zich houdt. Ik ben bang dat bij een call dat je daarmee ook shops 'called' waar de voorraad in de tussentijd niet is veranderd. Wat is de snelheid van een call?
Waar het allemaal inderdaad om draait is dat een request zo snel mogelijk het gewenste resultaat oplevert. Het is om te beginnen ook belangrijk dat er redelijk snel begonnen kan worden met testen en dus met een recht door zee manier te beginnen.
Maar:
Indien het van belang is dat de data up to date is moet je misschien inderdaad een API endpoint voorzien voor jouw globale database, maar dan moet je ervoor zorgen dat die 20 shops een API-call sturen naar jou om de voorraad etc. up te daten. Dan moet jij zelf niet gaan "vragen" om data aan die 20 shops.
Gewijzigd op 24/04/2019 18:11:57 door Jelle Dnw
Inderdaad een mogelijkheid voor de shops om wijzigingen in hun voorraad door te geven is daarom echt belangrijk.
Is het nodig om iedere shop in dezelfde 'taal' te laten communiceren met de API? Zou het kunnen dat de aangeleverde informatie, in een bepaald stadium tussen de API-call en de daadwerkelijke wijziging in de globale database, nog wordt geconverteerd naar bijvoorbeeld MySQL?
Na een zoekactie op Google wordt ik overspoelt met verschillende informatie. Is er een tool/programma om een API te maken? Of bestaan er een soort van 'standaard' die als basis kan worden gebruikt?
De verwerking binnen je API zorgt ervoor dat bij jou de data up to date geraakt, dus "converteren" is hier niet aan de orde. Je zorgt binnen je verwerking er gewoon voor dat je je database update wanneer je dat type request binnenkrijgt.
Hoe cool zou het zijn om hier echt een standaard van te maken (en misschien is die er al?), zodat *iedereen* op een uniforme wijze voorraadbeheergegevens kan uitwisselen? Dit zou de drempel voor winkels ook een stuk lager maken, immers, ze hoeven dan maar één extensie te installeren om al de geïnteresseerde partijen te bedienen, in plaats van het aanbrengen van een custom ding per individuele partij.
Dit lijkt mij ook het idee van een standaard, iedereen maakt gebruik van hetzelfde ding, in tegenstelling tot het steeds opnieuw creëren van een eigen standaard...
Of je gaat ergens in het midden zitten, net zoals payment service providers, en slaat dan een brug tussen alle mogelijke systemen die er al zijn, en een gestandaardiseerd eindpunt voor de afnemers. Welk specifiek systeem elke individuele partij dan gebruikt is dan niet langer relevant.
Gewijzigd op 26/04/2019 14:49:03 door Thomas van den Heuvel
Ik kan me niet voorstellen dat jouw applicatie hetzelfde gaat doen, want dan had je die partijen wel gekend. Bovendien heb je geen schijn van kans als je niet weet hoe een WMS (warehouse management system) ongeveer werkt.
Je zult echt concreter in kaart moeten brengen wie en wat je precies wilt gaan koppelen, anders blijft het bij luchtfietserij.
Met weinig programmeer-ervaring zal je dit niet zo eenvoudig kunnen opbouwen. Als je weinig van programmeren af weet, begin dan liever aan simpele dingen en zet complexe koppelingssystemen en WMS'en een tijdje in de ijskast totdat je echt meer ervaring met programmeren hebt opgedaan. Anders heb je kans dat je in de knel komt, en dat de moeite voor niks is.
Ter vergelijking: Tijdens mijn begin aan PHP in 2004 had ik al moeite om een fatsoenlijk forum bij mijn site te bouwen, want er waren echt een hoop dingen om rekening mee te houden (telling van reacties/topics, rechten, koppelingen met diverse tabellen. Uiteindelijk is het gelukt, maar een WMS-systeem is overigens ook een behoorlijk basaal systeem wat nog complexer is, en waarbij je ook kennis moet hebben van bepaalde theorieën over het beheren van producten. Dat gaat zelfs verder tot aan details zoals aantallen, vormen, kleuren en prijzen.
Gewijzigd op 26/04/2019 18:58:35 door - Ariën -