Koppelen + uitlezen MySQL en andere type databases

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Web Ontwikkelaar PHP, Nijmegen

Contactpersoon Roel Kavelaar rkavelaarATsearch-consult.nl 0243528815 0644949337 Organisatie Jong, gezond en sterk groeiende bedrijf dat webbased multimedia oplossingen bouwt in de omgeving Nijmegen. Het bedrijf bouwt voor klanten o.a. geavanceerde websites, webwinkels, webapplicaties en specifieke webbased software. Het bedrijf ontwikkelt en onderhoudt ook verschillende bekende Nederlandse websites. Op dit moment hebben zij een groeiende en brede klantenkring opgebouwd. Met betrekking tot programmeer-, onderhoud-, ontwerp-werkzaamheden wordt een PHP ontwikkelaar gezocht met kennis van contentmanagementsysteemen en frameworks. Locatie Nijmegen Verantwoordelijkheden (Her)Ontwerpen en (her)ontwikkelen in PHP ten behoeve van websites voor klanten, project klussen, onderhoud en specifieke klantwensen (Her)Ontwerpen en (her)ontwikkelen in PHP, PHP

Bekijk vacature »

Pagina: « vorige 1 2

Thomas van den Heuvel

Thomas van den Heuvel

20/04/2019 21:18:55
Quote Anchor link
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.
 
PHP hulp

PHP hulp

18/07/2019 01:29:27
 
Casper Richelle

Casper Richelle

21/04/2019 00:24:13
Quote Anchor link
De werkwijze zal ik in de loop der tijd wel naar mijn hand zetten om zo een eenduidig systeem te ontwikkelen.
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
 
- Ariën -
Beheerder

- Ariën -

21/04/2019 00:27:50
Quote Anchor link
Dan zou die aanbieder iets in de vorm van een PUSH-mechanisme op moeten zetten.
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 -
 
Casper Richelle

Casper Richelle

21/04/2019 10:53:28
Quote Anchor link
Wat bedoel je precies met wat hun mogelijkheden zijn? Bedoel je hiermee mogelijkheden obv bestandstypen etc?
 
- Ariën -
Beheerder

- Ariën -

21/04/2019 11:27:45
Quote Anchor link
Hoe hun de data vrijgegeven.
Neem eens contact met hun op, of spit eens door hun documentatie. Elke site kan het weer anders aanbieden.
 
Casper Richelle

Casper Richelle

21/04/2019 19:28:58
Quote Anchor link
Aah op die manier! Ben inderdaad al bezig met verschillende webshops en zelf ook een feed aan het maken om het uit te kunnen vogelen!

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?
 
Rob Doemaarwat

Rob Doemaarwat

21/04/2019 20:53:52
Quote Anchor link
PUSH: de andere partij drukt (push) het bij jou naar binnen.
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".
 
Casper Richelle

Casper Richelle

23/04/2019 15:02:02
Quote Anchor link
Hartelijk dank allen voor jullie reacties! Voor dit moment heb ik genoeg informatie om te beginnen.
Bij eventuele vragen/adviezen kom ik graag terug voor jullie expertise!

Met vriendelijke groet,

Casper
 
Jelle Dnw

Jelle Dnw

23/04/2019 16:09:43
Quote Anchor link
Je kan dit op diverse manieren gaan doen. Het belangrijkste hier is dat het opvragen van de data de request niet vertraagt. Je wil dus best de data up to date houden achter de schermen, dus onafhankelijk van de request van de gebruiker. Hierbij kan je best werken met RabbitMQ (of een ander soort queue systeem) die bijvoorbeeld een API call verstuurt waarbij je data opvraagt van de verschillende shops. Deze dienen dan wel een goede endpoint te hebben (bv. REST-api). Deze commands kan je offloaden op de queue en in de achtergrond runnen.

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.
 
Casper Richelle

Casper Richelle

24/04/2019 16:53:43
Quote Anchor link
Hoi Jelle! Bedankt voor jouw reactie!

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.
 
Jelle Dnw

Jelle Dnw

24/04/2019 17:49:21
Quote Anchor link
Je gaat altijd wel een kleine vertraging hebben als je 20 databases wil uitlezen naar één grote op je server. Beste wat je hier kan doen is een console script draaien in combinatie met een queue om al die data in te lezen. Op die manier gebeurt alles op je server en merkt de gebruiker hier niets van als deze de website gaat bezoeken. De request van de gebruiker naar de server en je API-calls gebeuren onafhankelijk van elkaar op deze manier. Frequentie bepaal je hiervan zelf, maar je mag je server ook niet teveel belasten.

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
 
Casper Richelle

Casper Richelle

25/04/2019 15:15:21
Quote Anchor link
Het belang van een up to date voorraad staat wel centraal. Want zonder kloppende informatie is onmogelijk om te zorgen voor een goede klantbeleving.

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?
 
Jelle Dnw

Jelle Dnw

26/04/2019 14:09:59
Quote Anchor link
Nee, een REST-api is universeel. Je doet gewoon een request van een bepaald type naar de endpoint dus het maakt niet uit in welke taal dat geschreven is die call.

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.
 
Thomas van den Heuvel

Thomas van den Heuvel

26/04/2019 14:47:03
Quote Anchor link
Misschien een verre schot voor de boeg: waarschijnlijk gaat dit alles wel (technisch) lukken en misschien krijg je die winkels zelfs zo ver om jou direct van informatie te voorzien, maar... in zekere zin heb je dan nog steeds een wiel uitgevonden voor die shops.

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
 
Ward van der Put
Moderator

Ward van der Put

26/04/2019 18:48:42
Quote Anchor link
Er zijn al verschillende bedrijven die dit type datakoppelingen leveren voor retail en e-commerce. En zij kunnen vrijwel elk denkbaar type input omzetten in bijna elke gewenste output.

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.
 
- Ariën -
Beheerder

- Ariën -

26/04/2019 18:56:27
Quote Anchor link
Hoewel het topic al best een informatieve uitstraling heeft, sluit mij bij Ward aan, en vooral omdat het topic begint met: "Om te beginnen ben ik een leek op het gebied van programmeren en ben op zoek naar advies van jullie!"

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 -
 

Pagina: « vorige 1 2



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.