Het is de bedoeling dat ik in de database laat zoeken of 1 van de 3 dingen gevonden wordt.
Bij al reeds bestaande moet namelijk geen nieuwe aangemaakt worden.
Ik gebruik daarvoor deze code:
Echter werkt nu alleen de title controle (de eerste).
De andere 2 dingen worden genegeerd (ook al is het aanwezig in de database wordt er evengoed toegevoegt).
Iemand enig idee wat ik fout heb aan die regel?
Het gaat om deze regel:
$item_exists_sql = "SELECT news_title, news_body, news_thumbnail FROM e107_news where news_title = '" . $titel . "' OR news_body = '" . $content . "' OR news_thumbnail = '" . $afbeelding . "'";
Uhm, links in RSS feeds zouden permalinks moeten zijn bij mijn weten :/.
Als je dan toch de feed binnenhaalt zou je ook kunnen overwegen om alle links van die RSS-bron weg te gooien, omdat je er blijkbaar niet (meer) vanuit kunt gaan dat de desbetreffende artikelen nog bestaan.
Dit klinkt als een update-probleem. In plaats van met veel moeite proberen te bepalen of een artikel nog bestaat (wat trouwens mislukt als alle data verandert) kun je ze beter wegggooien en opnieuw toevoegen, dat lijkt mij een stuk simpeler en minder foutgevoelig.
Het punt is dat dat geen optie is omdat op mijn eigen site ook reacties gegeven kunnen worden op de artikelen.
Daarom moet het via bovenstaande manier met het risico dat als alles een keer veranderd wordt het dan dubbel komt te staan, maar dat is dan verder niet te voorkomen en komt maar zelden voor.
Ik laat wel de aangepaste de oude overschrijven maar dan blijven de reacties behouden.
Echter moet ik nu alleen nog voor elkaar zien te krijgen dat hij het gedeelte met de URL (in mijn database dus) niet meeneemt in de vergelijking omdat het zo altijd anders is.
Uiteraard vervang ik daarna de URL naar de nieuwe, maar eerst moet die check werken (als dat al mogelijk is).
In een RSS feed hoort elk item een permalink te hebben, dus kijk dat nog even na.
Het probleem met zoeken naar inhoud is dat het ontiegelijk traag is, LIKE is zo'n beetje het slechtste wat je kunt doen (tenzij je trigram indexes kunt gebruiken).
Wat je sowieso kunt doen is md5 hashes opslaan voor de drie onderdelen. De kans dat twee items op dezelfde publicatiedatum dezelfde md5 hebben voor de titel is nul, niemand maakt twee artikelen met dezelfde titel op dezelfde dag. Dus, als je een nieuw item binnenkrijgt kun je in de database zoeken naar de publicatiedatum en dan per artikel kijken of er hashes overeenkomen. Dat faalt alleen als het hele artikel wordt aangepast en dan kun je altijd nog aan de gang met levenshtein om te zien hoeveel verschillen er zijn; degene met de minste verschillen zal wel het juiste zijn.
Ik doe het nu via de manier LIKE idd en dat werkt goed!
Op dit moment is het niet traag en het is eigenlijk maar voor een hobby site dus ik hou het wel even in de gaten.
Ik weet niet of het onder reclame maken valt (dat is echt niet mijn bedoeling) maar als jullie willen zien hoe het geworden is kun je dat zien op www.effebuurten.nl
Dat is vaak het geval met een ontwikkel-omgeving met daarin hooguit 10 nieuwsberichten of webshop-artikelen. Maar als het aantal oploopt, komt er een moment dat het ineens wel traag is.
En dan wordt het uitstel, want valt nog wel mee, nog meer uitstel want even geen tijd, en afstel want code is toch al best oud en waar stond het ook weer.
Zorg bij voorkeur ervoor dat het direct goed is. Het kan geen kwaad om met 10 artikelen 5 ms winst te halen, maar met 10.000 artikelen in je database wil je wel graag die 90 seconden winst hebben van 91 naar 1 seconde.
En stel dat je site inderdaad voor hobby gebruik is en je nooit boven de 30 berichten komt: het zou toch leuk zijn als je de scripts later hergebruikt voor een andere situatie waarin wel veel data gebruikt wordt het niet direct omvalt.
