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: 1 2 volgende »

Casper Richelle

Casper Richelle

19/04/2019 12:22:19
Quote Anchor link
Beste lezer,

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
 
PHP hulp

PHP hulp

18/07/2019 01:25:42
 
Ivo P

Ivo P

19/04/2019 12:32:19
Quote Anchor link
voilà de handleiding van PHP: https://www.php.net/manual/en/refs.database.php

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

- Ariën -

19/04/2019 12:36:43
Quote Anchor link
Het lijkt mij zinniger om data uit je csv, xml, xls, txt formats te importeren in MySQL. Voor csv zijn er eenvoudige functies voor:

http://www.mysqltutorial.org/import-csv-file-mysql-table/
 
Adoptive Solution

Adoptive Solution

19/04/2019 12:50:56
Quote Anchor link
csv bestanden kan je als database gebruiken met :
http://www.pjj.pl/pjjtextbase/

Ook is er nog Sqlite :
https://www.sqlite.org/index.html
 
Casper Richelle

Casper Richelle

19/04/2019 14:11:57
Quote Anchor link
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.


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

- Ariën -

19/04/2019 14:29:04
Quote Anchor link
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?
 
Ivo P

Ivo P

19/04/2019 14:44:17
Quote Anchor link
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.
 
Casper Richelle

Casper Richelle

19/04/2019 15:19:11
Quote Anchor link
- 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.



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

- Ariën -

19/04/2019 16:25:07
Quote Anchor link
Dan raad ik aan om alles in MySQL te importeren, zodat je alles bij elkaar hebt. De feed van de webwinkels waarvan je de data wilt gebruiken zijn vooral bedoeld voor export. Ze slaan alle data vast niet op in dergelijke bestanden. ;-)

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

Thomas van den Heuvel

19/04/2019 16:27:40
Quote Anchor link
Los van dit alles lijkt het mij handig om één (gestandaardiseerde) bron te raadplegen in plaats van tig bronnen en dan alle resultaten op een of andere manier te combineren.

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

- Ariën -

19/04/2019 16:44:07
Quote Anchor link
...en welk formaat het is, en hoe dit opgebouwd is.
 
Thomas van den Heuvel

Thomas van den Heuvel

19/04/2019 16:50:48
Quote Anchor link
Uiteraard, er zal daarbij dus ook een soort van vertaalslag plaats moeten vinden om er ook daadwerkelijk één geheel van te maken.
 
Casper Richelle

Casper Richelle

19/04/2019 17:21:51
Quote Anchor link
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.
 
Thomas van den Heuvel

Thomas van den Heuvel

19/04/2019 17:33:55
Quote Anchor link
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.
 
Casper Richelle

Casper Richelle

19/04/2019 17:46:43
Quote Anchor link
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).
 
- Ariën -
Beheerder

- Ariën -

19/04/2019 19:09:49
Quote Anchor link
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.

In jouw database ziek je dan alles.
Gewijzigd op 19/04/2019 19:10:41 door - Ariën -
 
Thomas van den Heuvel

Thomas van den Heuvel

19/04/2019 20:11:52
Quote Anchor link
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.
 
Casper Richelle

Casper Richelle

20/04/2019 16:16:18
Quote Anchor link
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
 
Rob Doemaarwat

Rob Doemaarwat

20/04/2019 19:06:24
Quote Anchor link
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.
 
Casper Richelle

Casper Richelle

20/04/2019 19:46:23
Quote Anchor link
Hoi Rob!

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

- Ariën -

20/04/2019 20:20:55
Quote Anchor link
Er bestaan diverse databases: Oracle, PostgreSQL, SQLlite, MongoDB, Redis maar MySQL en MariaDB (beiden in de praktijk hetzelfde) worden het meest gebruikt.
Gewijzigd op 20/04/2019 20:21:58 door - Ariën -
 

Pagina: 1 2 volgende »



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.