Om te beginnen ben ik een leek op het gebied van programmeren en ben op zoek naar advies van jullie!
Momenteel ben ik bezig met een project waarbij ik verschillende databases, voornamelijk MySQL, maar zeker ook andere type databases zoals .csv, .txt, .xml en .xls wil koppelen aan een website/platform.
Het is de bedoeling dat obv van een zoekopdracht op het platform/website er een request naar de aangesloten databases gaat en er wordt teruggekoppeld of er informatie in de database zit die voldoet aan de zoekopdracht.
Na wat eigen onderzoek heb ik gelezen dat het middels PHP mogelijk is om een MySQL database te koppelen. Is het met PHP ook mogelijk om de andere type databases te koppelen?
Zijn is mogelijk 'standaard' tools of scripts die voor deze koppeling kunnen zorgen en op welke manier krijg ik de informatie uit de verschillende databases?
(Excuus als dit wat veel vragen zijn, maar ik probeer het voor mezelf duidelijk te hebben hoe het werkt aangezien ik het als complete leek, erg interessant vind!)
Inderdaad veel handiger om alles in een gestandaardiseerde bron te raadplegen. Dit zal dan MySQL worden, aangezien merendeel al met MySQL werkt. Op internet heb ik een aantal scripts gevonden die kunnen zorgen voor het importeren van verschillende type bestanden naar een MySQL database, dus ik neem heel voorzichtig aan dat het voor nagenoeg alle, door webwinkels, gebruikte bestandtypen mogelijk is om het te importeren naar MySQL.
De frequentie waarmee de bestanden veranderen hangt volledig af van verkopen die in de tussentijd gedaan worden.
Zelf zat ik te denken dat het 'ophalen' van de laatste versie van de verschillende bestanden enkel nodig is zodra er daadwerkelijk een zoekopdracht plaatsvindt. Maar ik kan me voorstellen dat als er meerdere zoekopdrachten per minuut/seconde gedaan worden dat dit mogelijk niet de beste manier is.
Het is de bedoeling dat na de zoekopdracht de realtime voorraden beschikbaar zijn.
Het is de bedoeling dat na de zoekopdracht de realtime voorraden beschikbaar zijn.
Sja, maar er zit mogelijk een vertraging in het updaten van die bestanden, tenzij daar rechtstreeks de boekhouding wordt geregeld, wat mij sterk lijkt.
Vervolgens zit er een vertraging door de importfrequentie, tenzij je dat dus elke keer voor een zoekopdracht doet, maar dan staat die zoekopdracht mogelijk minutenlang te stampen.
De enige manier om dit te omzeilen lijkt mij een enkele (centrale) bron waar de voorraad wordt bijgehouden, die je rechtstreeks kunt raadplegen. Op het moment dat de data over meerdere plaatsen is verdeeld krijg je overhead, vertragingen, mogelijk verouderde informatie et cetera. Dat is haast onvermijdelijk.
Aan wat voor vertragingen moet ik dan ongeveer denken? De centrale bron spreekt mij inderdaad ook het meest aan.
Zou het mogelijk zijn om bijvoorbeeld per database een script te runnen ipv dat een enkel script alle databases aan zou moeten spreken? (Ik denk als complete leek nu hardop).
Alles hoor je in één database op te slaan. De data uit alle feeds (dus niet hun databases) van de webwinkels importeer je dus om de zoveel tijd in je database.
Ik bedoelde meer dat de verschillende aangesloten webwinkels zelf alle met een centraal systeem werken :). Maar als je daar geen controle over hebt dan wordt het middelen.
Ik bedoelde meer dat de verschillende aangesloten webwinkels zelf alle met een centraal systeem werken :). Maar als je daar geen controle over hebt dan wordt het middelen.
Ik begrijp niet helemaal wat je bedoeld, maar ik vat het als volgt op:
De aangesloten webwinkels moeten inderdaad werken/gaan werken met een centraal systeem en dit zal ik dan moeten exporteren naar een groot gezamelijke database.
Zijn er naar een gezamenlijke database nog andere mogelijkheden denkbaar? Zou het mogelijk zijn om elke webwinkel op een eigen MySQL database te laten draaien en per database dan per database een koppeling te maken? Dit omdat winkels zo goed als allemaal andere prijzen hanteren voor dezelfde producten.
[size=xsmall]Toevoeging op 20/04/2019 16:35:26:[/size]
Zojuist heb ik wat doorgezocht op andere manieren en kom terecht op REST API.
Beslist.nl maakt hier bijvoorbeeld gebruik van. In de feedhandleiding van Beslist lees ik dat verwerking van de informatie zowel doorlopend als direct is.
Betekend dit ook dat aangesloten winkels die met deze REST API van Beslist werken ook daadwerkelijk doorlopende wijzigingen in de voorraad doorgeven?
Ten eerste: Ik krijg het idee dat je een te grote stap in 1x wilt maken: alsof je net je eerste papieren vliegtuigje hebt gevouwen, en nu meteen een straaljager wilt gaan bouwen. Je zult vast een fantastisch idee hebben, maar misschien moet je een flinke stap terug doen, en dan met wat kleinere stapjes op je doel af gaan. Zodanig dat je elke stap kunt overzien en begrijpen, voordat je jezelf in het volgende ravijn van problemen ("uitdagingen") stort.
Dan wat betreft synchroniseren: je kunt synchroon en asynchroon aan de slag.
Synchroon: Een wijziging in de voorraad van de winkel wordt direct aan jou doorgegeven (artikel d'r bij, artikel d'r af, enz). Dit moet blijven kloppen, want als je een paar keer een stukje informatie mist loopt het helemaal spaak (jij denkt dat ze er nog 2 op voorraad hebben terwijl ze in werkelijkheid helemaal uitverkocht zijn - of er juist nog 5 hebben). Vaak wordt daarom nog eens in de zoveel tijd een compleet overzicht doorgestuurd, zodat je zeker weet dat alle tellers weer op dezelfde waarde staan.
Asynchroon: De winkel geeft eens of een paar keer per dag de wijzigingen door, of gewoon steeds een compleet overzicht. Je weet dus nooit zeker wat er precies op voorraad is omdat je altijd een beetje achter loopt. Dit is vaak wel eenvoudiger omdat je geen real-time interface nodig hebt. Ze kunnen bijvoorbeeld gewoon eens in de zoveel tijd een compleet overzicht (CSV-bestand) naar je toe FTP-en.
Al deze data zal echter in allerlei formaten naar je toe komen, tenzij je een grote jongen bent, zoals beslist.nl (waardeloze site overigens), dan kun je waarschijnlijk wel een bepaalde interface opdringen aan de winkels (en zelfs dan zullen de grote winkels toch liever hebben dat jij je naar *hun* methode voegt). Het formaat van de bestanden zal dus anders zijn (CSV, XML, enz), maar daarbinnen ook de indeling en zelfs de manier waarop de data wordt aangeleverd. De ene levert bijvoorbeeld prijzen met een komma als decimaal scheider ("12,34"), de ander een punt ("12.34") en weer een ander in centen ("1234" - want dan heb je geen gedoe met punt *of* komma). Datums kun je natuurlijk ook op diverse manieren schrijven, enz. Ook zal niet iedereen alle informatie aanleveren (wel/geen omschrijving, wel/geen leeftijdsindicatie, zo zijn er nog wel van dat soort randgevallen; de een zal evt. foto's meesturen in een ZIP / uploaden / enz, bij de ander krijg je alleen een URL en zul je ze zelf op moeten halen, enz).
Voor je eigen gemak zul je deze verschillen eenmalig glad willen strijken (en niet bij/tijdens elke zoekopdracht). De data komt dus bij je binnen / haal je op, en daarna converteer je het naar je eigen indeling. Dit zou in een MySQL database kunnen, maar dit kan natuurlijk van alles zijn, als het uiteindelijk maar uniform is. En een database is hiervoor natuurlijk wel het handigste medium, ook omdat je dan later eenvoudig (eenduidig!) kunt zoeken. En daar ging het uiteindelijk om.
Ten eerste bedankt voor jouw reactie!
Het is inderdaad even groter uitgedacht dat waarmee ik in eerste instantie ga beginnen. Maar hierdoor wordt het voor mij wel een stuk duidelijker waar ik allemaal tegen aan kan lopen (verschillende formaten, en manier van aanleveren etc.).
De bedoeling zal wel zijn om synchroon te werk te gaan. Dit om de voorraden zo up-to-date mogelijk te houden.
Een centrale database met een eigen indeling zal inderdaad de basis worden om het zoeken 'eenvoudiger' te kunnen zoeken.
Zijn er naast MySQL nog andere soorten databases die in aanmerking zouden kunnen komen?
Er bestaan diverse databases: Oracle, PostgreSQL, SQLlite, MongoDB, Redis maar MySQL en MariaDB (beiden in de praktijk hetzelfde) worden het meest gebruikt.
