Arrays duplicates verwijderen case sensitive

Door Hans De Ridder op 25-09-2017 23:29 gewijzigd op 25-09-2017 23:31

2.411 views

Idee:
Ik geef mijn leden de mogelijkheid om een persoonlijke youtube top 20 samen te stellen.
Daarvoor moet ik uit de samengestelde lijsten eerst de duplicate items te verwijderen.
Het lukt wel, maar als de lege plekken verwijderen, dan wordt niet meer gekeken naar de case sensitive.
Dat komt door het toepassen van array_splice.
Iemand een mogelijkheid om een bruikbare array te produceren, die ik weer verder kan gebruiken?
Dit was een testje:


$arr0 =  array("TIjE6RIAv2s","Q4xyiJkX4vw","_5BzyInFf5M","q4xyiJkX4vw","91EbIgyFA1Y");
$arr1 =  array("tIjE6RIAv2s","Q4xyiJkX4vw","_5BzyInFf5M","vdufteeVZyo","CqkpWByCzL4");
$arr2 =  array("Bn1rdYzv4qM","Q4xyiJkX4vw","_5BzyInFf5M","vdufteeVZyo","-dY3s415TP0");
$arr3 =  array("Bn1rdYzv4qM","tIjE6RIAv2s","Q4xyiJkX4vw","vdufteeVZyo","s9bXNR9hdIk");

$arr= array_unique(array_merge($arr0,$arr1,$arr2, $arr3));

if ($arr[$i] =='')
{ 
array_splice($arr, $i, 1);
}

//$arr_length = count($arr);
$arr_length = 20;

for($i=0;$i<$arr_length;$i++) 
{ 
echo $arr[$i].'<br>';
}    

Zonder splice (11 stuks):

TIjE6RIAv2s
Q4xyiJkX4vw
_5BzyInFf5M
q4xyiJkX4vw
91EbIgyFA1Y
tIjE6RIAv2s


vdufteeVZyo
CqkpWByCzL4
Bn1rdYzv4qM



-dY3s415TP0




s9bXNR9hdIk

Met splice (10 stuks):

Q4xyiJkX4vw
_5BzyInFf5M
q4xyiJkX4vw
91EbIgyFA1Y
tIjE6RIAv2s
vdufteeVZyo
CqkpWByCzL4
Bn1rdYzv4qM
-dY3s415TP0
s9bXNR9hdIk

Thomas van den Heuvel

27-09-2017 16:56

Experimenteren en verkennen is goed, maar enig reflecteren op zijn tijd kan ook geen kwaad.

Er zullen momenten zijn (of komen) waarin je heroverweegt hoe je deze data gaat gebruiken.

Met de gekozen oplossing ben je nu al meteen je eigen informatie aan het repareren (wegfilteren van duplicaten), nog voordat je hier wat dan ook mee doet. Dit lijkt mij een indicatie dat dit anders en mogelijk beter kan. De data is niet direct "gebruiksklaar".

Nu zijn dit mogelijk nog persoonlijke top 20 afspeellijsten, maar misschien wil je op den duur wat statistieken introduceren (X gebruikers hebben video Y in hun afspeellijst staan), lijsten kunnen delen et cetera. Met de huidige opzet is dit een hels karwei, eerst moet je *alle* data uitpakken (en opschonen) voordat je uberhaupt kunt gaan meten en rekenen. Met de data valt niet (of in ieder geval niet makkelijk) te werken.

Andere programmeurs die je deze oplossing laat zien zullen waarschijnlijk hun wenkbrauwen fronsen, of het gemiddeld aantal wtf's per minuut doen laten stijgen. Bovenstaande code is ook niet voorzien van commentaarregels (geen annotatie). Meestal staat er in een verhaaltje kort uitgelegd wat alles doet en motiveert zijdelings ook WAAROM het op die manier gedaan is. Je zult dit op zijn minst naar jezelf toe moeten motiveren maar op dit moment is de code vanwege het ontbreken van commentaar niet erg leesbaar. Als iemand anders jouw werk om wat voor reden dan ook zou moeten inzien of zal moeten gebruiken heeft deze een dagtaak aan het reverse engineeren van wat er nu concreet gebeurt. Omgekeerd zou jij mogelijk ook ooit met code van anderen aan de slag moeten. Als er geen letter geannoteerd is is daar eigenlijk geen beginnen aan. Wat gij niet wilt dat u geschiedt... De code is niet transparant.

Even los van het feit dat IPTC bedoeld is voor het opslaan van metadata van afbeeldingen heeft deze waarschijnlijk limieten qua opslagruimte en/of de lengte van individuele velden. En mogelijk zul je ook character encoderingen in overweging moeten nemen. Deze dingen spelen nu mogelijk niet, maar wat als je iedereen een persoonlijke top 50 geeft en het dan niet past? Of dat je mogelijk exotische karakters gaat opslaan die vervolgens door de vleesmolen gaan. Mogelijk kom je dus in de knoei als je deze oplossing uitbouwt.

Bottom line is dat wat je gebruikt naar alle waarschijnlijkheid geen geschikt medium is voor wat je probeert te doen. Het is mede de verantwoordelijkheid van gebruikers van deze site ("vakgenoten") om je hier op te wijzen. Wat je hier vervolgens mee doet mag je zelf weten :).

Hans De Ridder

27-09-2017 21:46 gewijzigd op 27-09-2017 22:55

Bedankt voor je reacties.

Het zijn niet mijn lijsten, maar van leden.
Die kunnen ook afgespeeld worden op de website.
De website top 20 wordt samengesteld uit deze lijsten.
Voor mij is het straks van belang bij hoeveel leden
ik beter weer kan overgaan naar de database.
Dat is in principe niet zo'n probleem.
De opdrachten zijn niet zo verschillend tov database.
Een image is 1 x 1 pixel in jpg. Ongeveer 400b.
Met alle persoonlijke info wordt het ongeveer 1,5kb.

Elk lid heeft een eigen image.
Daar staat alle persoonlijke data opgeslagen.

Alle documenten in pdf worden images van gemaakt.
Meeste is tijdelijk.
Daarom worden die gegevens voor de layout in de image geplaatst.
Wordt de image verwijderd, dan is de data ook weg.
Mag/moet ook.
Youtube kent een eigen mogelijkheid om images te plaatsen.
Originelen worden pas bekeken/beluisterd als er geklikt wordt.

De images zelf hebben 31 posities om data te plaatsen.
Dat mag ook komma gescheiden zijn.
Ik ben nog geen problemen tegen gekomen bij data tot 2000 characters per regel.

Is voor mij helemaal nieuw.
En er is naast de eenvoudige oproep- en plaatsen script weinig gedocumenteerd bij PHP.
Er zijn wel classes gemaakt.

Het heeft zeker ook nadelen.
Bij een wijziging moet alle data van een image worden gevraagd.
De wijziging(en) doorvoeren, en alles weer terugplaatsen.
Het vraagt ook oplettendheid mbt veiligheid.
Maar ik vind het leuk om die grenzen allemaal op te zoeken.
Ook benieuwd hoe dit doorwerkt op verwerkings snelheden.
En op het dataverkeer.

Willem vp

27-09-2017 23:50

> Ook benieuwd hoe dit doorwerkt op verwerkings snelheden.
> En op het dataverkeer.

Als de gegevens op de server worden verwerkt, zal het dataverkeer niet hoger of lager zijn dan wanneer je de gegevens in een database hebt.

De verwerkingssnelheid zal allicht lager zijn dan bij een database, maar wanneer het om een beperkt aantal bestanden gaat, zul je dat niet echt merken. Vanaf een paar honderd bestanden (zo te zien staat alles in 1 directory) worden de toegangstijden wel steeds langer en ik verwacht dat je vanaf een paar duizend bestanden serieus rekening moet gaan houden met timeouts. Afhankelijk van je hardware misschien al eerder.

Een ander punt om in het achterhoofd te houden is concurrency. Wanneer een plaatje wordt herschreven, is het even niet beschikbaar. Als precies op dat moment een andere worker het plaatje wil inlezen, kan het misgaan. Onder meer om die reden slaan we op mijn werk bepaalde plaatjes op in een database. Dat zou in jouw geval ook nog een oplossing kunnen zijn: dan heb je én de voordelen van een database én je gegevens in IPTC. ;-)

Hans De Ridder

28-09-2017 01:25 gewijzigd op 28-09-2017 01:27

Dank voor je opmerkingen.
Het grootste deel van het herschrijven zijn wijzigingen in de persoonlijke gegevens.
Dus dat is prive. En niet beschikbaar voor andere leden.
Dat geldt in principe ook voor flyers (jpg) en documenten (pdf).
In principe laat ik van elke soort document er telkens maar 1 toe.
Die kan dan onder dezelfde naam vervangen worden of aangevuld.
Daar kan inderdaad het probleem optreden van wijzigen en bekijken tegelijk.
Maar uitsluitend de eigenaar van de image/document kan wijzigingen aanbrengen.
Zijn documenten als aangeboden, gevraagd, gestolen.
Zal in principe niet veel meer aan gewijzigd worden.
Wel goed om me er op te attenderen.
Dat zijn bovendien documenten en flyers,, die een beperkte levensduur hebben (2 weken?)
Ik maak me meer zorgen over het opslaan van de originele documenten.
Dat gaat wellicht bij meer leden een opslagprobleem geven.
Ik zoek naar opslag op een cloud, waar vanaf de website, of rechstreeks via
de leden, bestanden op gezet kunnen worden.
Ben nog niks zinnigs tegen gekomen. Ook niet met API.
Maar het is allemaal uit te breiden.
Dus eerst vrolijk verder borduren op idee....

Reageren

Inloggen om te reageren