datafeed mapping tabel

[rmfloris]

Goedendag,

ik ben in de wondere wereld van datafeeds gestapt. Nu werkt het script schitterend op wat kleine zaken na.

Een ding wat werkt, maar waar waarschijnlijk nog veel ruimte voor verbetering is, is de mapping tabel.
Omdat iedere datafeed anders georganiseerd is heb ik de mapping tabel in het leven geroepen. Dit zodat hij afhankelijk van de aanbieder, automatisch de juiste kolom selecteerd uit de download.

Nu heb ik het volgende:
$info[1][prijs] = 1;
$info[1][product_url] = 2;
$info[1][verzend] = 3;

Waarbij de 1 de winkel/affiliate aangeeft en het getal aan het einde welke veld dit is in de datafeed.

Mijn vraag is wat de beste/optimale manier van werken is.
* Deze mapping tabel iedere keer uit de DB halen (snel werken, makkelijk toevoegen van aanbieders) of
* de mapping tabel in het import bestand zetten (eventueel via een include).
* Of is het verstandig om de mapping tabel geheel anders te maken?

Hopelijk hebben jullie mooie adviezen voor mij om dit gedeelte te verbeteren.

 

[brbrbr]

Persoonlijk zou ik aan de rechterkant geen nummers gebruiken maar de veldnamen ( en dan als eerste slag de veldnamen automatish omzetten in nummers.)


Omzetten naar een database heeft naar mijn mening alleen nut als je er ook een admin formulier omheen zet, of je moet phpmyadmin een handig tool vinden.

Zelf ben ik begonnen met de feeds te configureren in een los tekst bestand, dat werkte op zich best goed en vlot. Later een admin tool omheen gemaakt. werkt nog beter en vlotter.

 

[rmfloris]

Ik gebruik juist de nummers omdat op deze manier ik het veld kan aangeven waar deze zich bevind in het datafeed bestand. Dus een nummer 1 = positie 1 in de datafeed, 2 = positie 2 etc.

Zou je een voorbeeld kunnen geven van hoe jou database model eruit ziet?

 

[ouwesmurf]

@rmfloris:
ieder heeft zo zijn voorkeur, ontstaan uit ooit opleiding, ooit verkregen startscript, ooit etc.etc.

Wanneer je uiteindelijk met scripts automatisch bestanden gaat downloaden, moet je ermee rekening houden dat daar al iets mee mis kan gaan. Gaat het downloaden wel goed, maar gaat het om giga bestanden, moet je rekening houden met de werkingslimiet die in jouw geval geldt voor php-scripts.

Dat beperkt een aantal zaken.
Wat ik doe, is geautomatiseerd (cronjob) het bestand halen èn downloaden als tekstbestand op de server, ivm veiligheden in dezelfde map als het script ( hoeft dan slechts chmod 666=unix en bij phpsuexec is zelfs dat niet nodig ).

Wat ik in datzelfde script na test op header en omvang wel doe, is een filtering op het hele bestand.
Voorbeeld : weet je op voorhand na een eerste test, dat die adverteerder gebruik maakt van [ b ] [ / b ] etc., kun je dat alvast met een replace wegwerken.
Wat je hier ook simpel kunt doen, is een meegeleverde header inruilen voor je eigen header.

Komen we dus uit bij die header : dan gaat mijn voorkeur niet uit naar nummers, omdat elk mens geneigd is om de betekenis te vergeten, zeker bij datafeed nummer 99.
Dus m.i. een header met namen die voor jou of juist je pagina, begrijpelijk zijn.

Is er nog voldoende tijd voor andere verwerking dan met include naar een volgscript.
Komen er in script 1 fouten voor, direct een mail naar je toe laten sturen en is voor jou begrijpelijk waar de fout ligt, kun je ook "het wat" aanduiden. Met 2 wordt dat alweer ingewikkelder.

Al moet een dergelijk mail-alert ook in het tweede script staan, voorzien van foutmomenten.

In dat 2e script kun verder gaan mappen, hetzij naar een finaal textdatabase bestand, hetzij een update-script naar MySQL, met aan het eind uiteraard een succes verhaal per mail naar jezelf, zodat je altijd nog even de pagina kunt bekijken en de updatedatum kunt bewaren.

Van download direkt naar de MySQL : daar zullen weinig voorstanders voor te vinden zijn. ;D

 

[rmfloris]

@ouwesmurf,

een link direct naar de DB was gelukkig al geen optie. Al veel over gelezen over de eventuele problemen...

De optie met namen lijkt toch de betere oplossing te zijn, maar nu is dan de vraag, hoe implementeer je dat? Ik mis nog even de link/structuur.

Stel, in mijn datafeed staan de volgende velden: naam, product_url, prijs, ean en verzendkosten. Alleen de volgorde in de datafeed kan anders zijn en er kunnen velden tussen zitten. Hoe leg ik dan de link tussen de datafeed en de manier waarop ze moeten worden ingelezen?

Voorbeelden zijn meer dan welkom.

 

[ouwesmurf]

Nu heb ik het volgende:
$info[1][prijs] = 1;
$info[1][product_url] = 2;
$info[1][verzend] = 3;
Waarbij de 1 de winkel/affiliate aangeeft en het getal aan het einde welke veld dit is in de datafeed.

Vervolgens : binnen een branche een aantal feeds - liefst van meerdere netwerken - naast elkaar leggen, en dan vaststellen met behulp van het plan dat jij wilt presenteren, welke gegevens en dus welke kolommen je nodig hebt bij csv en dat wordt dan je eigen favoriet "FlorisSchoenen_columnvalue" als je winkeltje over schoenen gaat .... en FlorisCosmetica_columnvalue als het over schoensmeer gaat. , maar in de columnvalue altijd dezelfde volgorde en namen. ( tip : momenteel is m4n het meest consistent en tradetracker het meest slordig ).

Bovenstaande citaat-gegevens leert dat info [ x ][ prijs ] etc de laatst ingelezen feed is, terwijl numeriek je eigen lijst zou moeten zijn. Die keer je dan om, en numeriek naar woorden , bijv.

FlorisSchoenen_prijs [ x ] = $info[ x ][ prijs ]
FlorisSchoenen_url [ x ] =$info[ x ][ product_url ]
FlorisSchoenen_verzend [ x ] =$info[ x ][ verzend ]

Stel, in mijn datafeed staan de volgende velden: naam, product_url, prijs, ean en verzendkosten. Alleen de volgorde in de datafeed kan anders zijn en er kunnen velden tussen zitten. Hoe leg ik dan de link tussen de datafeed en de manier waarop ze moeten worden ingelezen?

Conclusie : jij bepaalt de header en de volgorde in die header, vervolgens pluk je uit de datafeed - record de juiste waarden. Jouw header is de kopie van je database, de datafeed is een supermarktschap waar je uit winkelt.

Die header blijft dan in je script bewaard. Zou namelijk je eigen header noodgedwongen veranderd moeten worden, moet dat ook in de SQL-database, kan allemaal best, maar praat je over giga bestanden , probeer het te voorkomen door veel droog te oefenen. Betekent ook : een goed gemiddelde qua feed-inhoud is beter, dan uit te gaan van wat 1 adverteerder wel biedt en die andere 9 niet. En ten overvloede : er is nog steeds geen wet die bepaalt dat je alles uit een feed moet gebruiken.

Uiteindelijk verdwijnt de array FlorisSchoenen_column in je SQL database hetzij als nieuw, hetzij als totale update, hetzij als update van specifieke ( als prijs ) velden. Neem voor de laatste een aspirientje alvast in de aanslag.

Zou me ook nog voor kunnen stellen, dat je een vaste kolom neemt voor naam Netwerk, naam Adverteerder, datum laatste bijwerking en ........ een eigen content-waarde en duiding. Die laatste twee buiten de feed verwerking houden.

Praktijk voorbeelden worden voor mij steeds moeilijker omdat in de loop van de tijd van diverse scriptonderdelen de succesnummers in een script-bibliotheek verdwenen zijn, en dat wordt dan niet echt duidelijk om 60Kb even hier uit te printen. Anderzijds is het voor ieder te adviseren om ook een eigen bibliotheek samen te stellen die je telkens kunt aanroepen hetzij met classes hetzij met funkties, of beiden, zodat je niet altijd het wiel hoeft uit te vinden en je alles bij de hand hebt. Kunnen alle losse stukjes gewoon weg.

Droog oefenen of permanent toepassen kun je natuurlijk ook met ( voorkeur van brbrbr ) Joomla routines , maar ook met Affiliatemaster, Affilistore v2 , Pricetapestry, waar je je voorbewerkte datafeeds ook met mapping ingebakken in de admin-tool in het grote geheel kunt opnemen.
Kun je voor de schoonmaak van de feeds gebruik maken van Killink CSV, CSV editor van Francke, of de CSV editor van Tizma, respectievelijk shareware, cardware, shareware. Er zijn er gelukkig nog meer.

En wees ervan verzekerd, zelfs met die "kant en klaar produkten" blijft er nog genoeg te frutselen. Maar laat je niet weerhouden om de volgende vraag te stellen , er zijn nog genoeg forumleden die nog niet aan de beurt zijn geweest ;D