Fordelen med å gjøre som Dyret sier, å bruke en hash av bildedata, er at du kan finne om bildet allerede ligger på disk utifra bildet uten å tenke på filnavn. Dette er jo selvfølgelig et valg man må ta i forhold til app.design. Noe man får prentet inn hele tiden er å tenke fremtidsrettet, skrive gjenbrukbar kode med potensiale for videreutvikling. Det vil ihvertfall være lurt å unngå "spesial"-tegn som kolon i filnavn, med tanke på emigrering til andre filsystem. Tid for opplasting kan man jo i etterkant lese utifra alle brukte filsystemer, afaik, så det skulle ikke være noen grunn til å bruke tid i filnavnet på den måten. Da kan man heller bruke en funksjon tilpasset dette behovet. Dette gir også fordelen av å kunne referere til eksisterende dokumentasjon.
Kode
// PHP - uniqid
// string uniqid ([ string $prefix = "" [, bool $more_entropy = false ]] )
// Gets a prefixed unique identifier based on the current time in microseconds.
$fn = uniqid( $anleggID );
Jeg støtter også opp om Dyrets forslag om en "gateway"/"proxy"-system mellom frontend-backend til bildene. Dermed er det enklere å forandre struktur i backend, uten at det trenger å påvirke frontend av systemet. Dette kan være et veldig enkelt script som utgangspunkt, men implementeringen av et slikt utviklingsmønster gjør systemet mer fleksibelt for videreutvikling.
Nå er det vel et lukket system det er snakk om sannsynligvis, så SEO ikke er vesentlig, men det kan lønne seg å holde seg til gode SEO prinsipper uansett f.eks for å kunne henvise til, istedet for å dokumentere.