Koppelen + uitlezen MySQL en andere type databases
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!)
Met vriendelijke groet,
Casper
alleen zijn .csv, .txt, .xml en .xls geen van alle databases.
Misschien zijn het formaten waarin je data kunt opslaan, maar dan om te bewaren of over te dragen. Maar niet om in te zoeken.
http://www.mysqltutorial.org/import-csv-file-mysql-table/
http://www.pjj.pl/pjjtextbase/
Ook is er nog Sqlite :
https://www.sqlite.org/index.html
Ivo P op 19/04/2019 12:32:19:
alleen zijn .csv, .txt, .xml en .xls geen van alle databases.
Misschien zijn het formaten waarin je data kunt opslaan, maar dan om te bewaren of over te dragen. Maar niet om in te zoeken.
Misschien zijn het formaten waarin je data kunt opslaan, maar dan om te bewaren of over te dragen. Maar niet om in te zoeken.
Is het wel mogelijk om in deze bestandtypes te zoeken mbv PHP?
Toevoeging op 19/04/2019 14:15:24:
Wat voor andere type databases zijn er naast MySQL veel in gebruik door webwinkels? Nu ik weet dat .csv, .txt, .xml en .xls helmaal geen databases zijn?
Nogmaals dank voor jullie reacties @Ivo P, Arien en Adoptive Solution!
dus iets als: bestaat er een user met de gebruikersnaam "piet".
of "geen me alle gebruikersnamen, gesorteerd op geboortedatum".
Dat lukt inderdaad wel als je dat in een tekstbestand of csv zet. Alleen, je moet dan misschien wel eerst alle regels inlezen om te constateren dat de allerlaatste op regel 13045 inderdaad die naam had.
En met sorteren moet je dan alles inlezen en in PHP ordenen. En dat kan veel werk kosten.
Niet per se, want als het om een site gaat met 10 gebruikers, dan valt dat wel mee. Maar voor een site als PHPHulp via een bestand met gebruikers doet, zal het inloggen nogal traag worden.
- Ariën - op 19/04/2019 14:29:04:
Je kan er prima in zoeken met PHP. Maar is er een reden dat je met verschillende bestanden-formats wilt werken? Of ga je dit importeren naar MySQL?
De reden hierdoor is dat ik wil gaan zoeken in voorraden van webwinkels. Helaas gebruikt niet elke webwinkel een MySQL. De kleinere ondernemers met een webwinkel werken soms nog via Excel of vergelijkbare methoden. Maar als iedereen over zou gaan op MySQL zou dit uiteraard een hele hoop kunnen schelen!
Toevoeging op 19/04/2019 15:26:41:
Ivo P op 19/04/2019 14:44:17:
van een database verwacht ik de mogelijkheid om te zoeken en te sorteren.
dus iets als: bestaat er een user met de gebruikersnaam "piet".
of "geen me alle gebruikersnamen, gesorteerd op geboortedatum".
Dat lukt inderdaad wel als je dat in een tekstbestand of csv zet. Alleen, je moet dan misschien wel eerst alle regels inlezen om te constateren dat de allerlaatste op regel 13045 inderdaad die naam had.
En met sorteren moet je dan alles inlezen en in PHP ordenen. En dat kan veel werk kosten.
Niet per se, want als het om een site gaat met 10 gebruikers, dan valt dat wel mee. Maar voor een site als PHPHulp via een bestand met gebruikers doet, zal het inloggen nogal traag worden.
dus iets als: bestaat er een user met de gebruikersnaam "piet".
of "geen me alle gebruikersnamen, gesorteerd op geboortedatum".
Dat lukt inderdaad wel als je dat in een tekstbestand of csv zet. Alleen, je moet dan misschien wel eerst alle regels inlezen om te constateren dat de allerlaatste op regel 13045 inderdaad die naam had.
En met sorteren moet je dan alles inlezen en in PHP ordenen. En dat kan veel werk kosten.
Niet per se, want als het om een site gaat met 10 gebruikers, dan valt dat wel mee. Maar voor een site als PHPHulp via een bestand met gebruikers doet, zal het inloggen nogal traag worden.
Stel: winkel A heeft de merken X,Y en Z in haar voorraad.
De bedoeling is om obv een zoekopdracht bijvoorbeeld: Trui merk X maat L om enkel die informatie over de, al dan niet, beschikbaarheid van die betreffende trui te weergeven.
Dus er zal specifiek gezocht worden en niet bijvoorbeeld op: geef me alle truien (om even bij jouw voorbeeld te blijven).
Is het dan ook zo dat het bij een database met een voorraad van bijvoorbeeld 10.000 producten het dusdanig langzaam gaat? Of kan het script zich relatief snel door de database heen werken?
Als je in een database werkt, zijn aantallen van 100.000 in het algemeen geen enkel probleem.
Gewijzigd op 19/04/2019 16:39:00 door - Ariën -
Een beter plan is daarom wellicht: combineer dit alles tot één database. Hiertoe zul je dus met enige frequentie de XML-, CSV- en TXT-bestanden moeten synchroniseren met hun laatste versie (de bron) en deze vervolgens updaten in een database. En hoe je dit het beste kunt doen hangt weer af van de frequentie waarmee deze bestanden inhoudelijk veranderen.
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.
Quote:
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.
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).
In jouw database ziek je dan alles.
Gewijzigd op 19/04/2019 19:10:41 door - Ariën -
Thomas van den Heuvel op 19/04/2019 20:11:52:
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.
Toevoeging op 20/04/2019 16:35:26:
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?
Een prettig paasweekend en vriendelijke groet,
Casper
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?
Gewijzigd op 20/04/2019 20:21:58 door - Ariën -