Du må være registrert og logget inn for å kunne legge ut innlegg på freak.no
X
LOGG INN
... eller du kan registrere deg nå
Dette nettstedet er avhengig av annonseinntekter for å holde driften og videre utvikling igang. Vi liker ikke reklame heller, men alternativene er ikke mange. Vær snill å vurder å slå av annonseblokkering, eller å abonnere på en reklamefri utgave av nettstedet.
  10 2176
Sikkerhetsklarert
Jeg driver med et lite prosjekt der oppgaven er å lage et system for å holde oversikt over div anlegg/bygg. Jeg har tidligere tråder her om å implentere google maps for å vise geografisk plassering av disse anleggene.

Nå ønsker oppdragsgiver å ha mulighet for å laste opp en eller flere bilder og knytte disse opp mot hvert anlegg.

Så lurer jeg da på om jeg bør lagre selve bildet som i mysql (blob), eller som en ren fil på webhotellet, og bare legge linken til bildet i databasen.

Det vil ikke være snakk om mange bilder. Og rent praktisk vil begge løsninger fungere.

Fordelen med å lagre som fil er at det sannsynligvis vil være kjappere å laste sidene, og å vise "galleriet", for skal jeg laste de fra databasen så trenger jeg en egen php funksjon for å sette sammen datastrømmen i database og vise det som bilde.

På den andre siden så vil det å lagre dette i mysql være en fordel når det kommer til det å ta backup, da holder det å dumpe databasen til en fil, og alt av info vil være der.

Noen her som har erfaringer rundt dette? Hva er best practice?
Vil tro å lagre hele filer i databasen vil være en unødvendig påkjenning for den. Selv lagrer jeg bildene som vanlige filer og bare har filnavnene i databasen.
Sist endret av EvveDevve; 3. januar 2014 kl. 16:16.
Jeg må ærlig innrømme at jeg ikke vet hva best practice er for sider i større skala, men det kommer litt an på bruksområde. Altså skalaen av antall bilder, størrelsen på disse, antall besøk, hyppighet på besøk, hvor mange bilder som skal lastes og om de lastes i et gitt mønster, samt om det er behov for å oppdatere de etc. Jeg antar at diskplass er billigere enn CPU-bruk, så best skalering får du nok ut av et filbasert system (og heavy caching).

For relativt få bilder så er det egentlig ett fett hva du gjør. Hvis du oftest viser enkeltbilder er det også forholdsvis lett å lagre disse i en database og hente de fram. Men med en gang du henter store mengder bilder ofte, så ville jeg begynt å gjøre noen forsøk på begge deler. Et alternativ er da å ha en mellomting som sjekker en cache før et bilde eventuelt hentes ut.

Det er uansett en stor fordel å ha bildeinfo i en database. Da kan du enkelt embedde et bilde vha. en referanse, og så slår databasen opp at "bilde-av-hovedbygg.jpg" skal peke på filen "3819fbda69ca26d89e07fe06266e8e228d72c2da" på disken, det er et bilde av typen JPEG, har dimensjon MxN, ble lastet opp av Bruker X, eies av Person Y, osv. Da kan du også oppdatere databasen til å peke på et nytt bilde uten å måtte endre på noen templates. Det du må gjøre er å tenke litt på hvordan det er enklest for brukerne å laste opp bilder, finne et bilde i havet av alle bildene og slette/oppdatere enkeltbilder.
Best practice er trolig å benytte goog.net.IframeIo i Google Closure til filopplasting.

Gjør deg selv en tjeneste, gjør som EvveDevve sa:
Sitat av EvveDevve Vis innlegg
Vil tro å lagre hele filer i databasen vil være en unødvendig påkjenning for den.
Selv lagrer jeg bildene som vanlige filer og bare har filnavnene i databasen.
Vis hele sitatet...
eller de ordene jeg ville benyttet for å si det samme: ikke last opp bilde til en blob, legg kun basename i databasen, med mindre du opererer med mapper, da må du legge inn hele stien og filenavnet.

Husk å filtrere ut kjørbare filer, dersom noen prøver å laste opp .php, pl, phtml, sh/bat, py, pyc, o l filer,
er du trolig interessert i å endre navn i opplastingsprosessen til .phps eller .txt

goog.net.IframeIo er metoden som benyttes ved opplasting av bilder til Google+

Litt dokumentasjon: http://docs.closure-library.googleco..._IframeIo.html

Go'boken: http://shop.oreilly.com/product/0636920001416.do
Sist endret av nudo; 3. januar 2014 kl. 18:22.
Sikkerhetsklarert
Trådstarter
Endte opp med å lagre til filsystem, og legge url og annen bildeinfo i DB.

Dyret, hva mente du med dette?
Da kan du enkelt embedde et bilde vha. en referanse, og så slår databasen opp at "bilde-av-hovedbygg.jpg" skal peke på filen "3819fbda69ca26d89e07fe06266e8e228d72c2da" på disken
Vis hele sitatet...
Tanken min var filnavnet i databasen skal stemme med filnavnet på disk.

Nudo, jeg har ikke satt meg inn i det google rammeverket. Er det slik at dette benyttes for å laste opp filer til google?
Sitat av Pjukern Vis innlegg
Dyret, hva mente du med dette?
Tanken min var filnavnet i databasen skal stemme med filnavnet på disk.
Vis hele sitatet...
Dette gjøres fordi at da får alle bildefiler random genererte navn på disk og ikke kan "kræsje" med hverandre.
Sist endret av Hager; 5. januar 2014 kl. 21:17.
Sitat av nudo Vis innlegg
Best practice er trolig å benytte goog.net.IframeIo i Google Closure til filopplasting.
Vis hele sitatet...
Best practice er å lagre det til disk på den måten som passer best til forskjellige rammeverk/programmeringsspråk, selv etter 10 år har jeg aldri hørt om det du mener er "best practice.".

Sitat av Dyret Vis innlegg
Jeg må ærlig innrømme at jeg ikke vet hva best practice er for sider i større skala
Vis hele sitatet...
Lagre det på disk først som sist, jo lengre en venter med å få de vekk fra DB jo mer helvete vil det bli. Rekorden jeg har måtte håndtere har vært en MySQL-database på oppimot 1TB med binærdata. Backup av den databasen var ikke morsomt.

Å ha oppimot millioner av bilder på disk er ubehagelig mtp IO, men det er som en drøm i forhold til å ha det i en database.
Sitat av Pjukern Vis innlegg
Dyret, hva mente du med dette?

Tanken min var filnavnet i databasen skal stemme med filnavnet på disk.
Vis hele sitatet...
Sitat av Hager Vis innlegg
Dette gjøres fordi at da får alle bildefiler random genererte navn på disk og ikke kan "kræsje" med hverandre.
Vis hele sitatet...
Riktig. Det fysiske bilde på serveren bør være frikoblet fra navnet, i tilfelle brukere laster opp egne bilder. Det blir fort litt gammelt om de må komme på unike navn hver eneste gang, og etterhvert ganske mange "asdfsf.jpg". Spesielt ille blir det med bilder som følger systematiske navn som "DSCN0001.jpg" eller "Image001.jpg" (eller når en tosk laster opp "æøå.jpg" med UTF7). Alternativene da er å enten lage en mappestruktur, legge til noe tilfeldig i navnet ved hver kollisjon (inntil ingen kollisjoner skjer), eller rett og slett gi opp å bruke navn. God praksis her er å ta en hash av bildedataene, rename bildet til det, og så la interne referanser til bildene peke til det nye navnet. Dette kommer som sagt veldig an på bruksområdene, men jeg så for meg noe sånt:

bildeDB: id, referansenavn, bildeinformasjon, filnavn-på-disk
albumDB: id, albumnavn, bilde-id'er-i-albumet

Da har du mange muligheter åpne for opplastere. Du kan velge å la brukere som legger ut bilder referere til navn/id i sin markup, og så omskriver du linkene til de "stygge" navnene (img src="img/3819fbda69ca26d89e07fe06266e8e228d72c2da.jpg). Et annet alternativ er å ha et script av typen "(...)/bilde.php?id=id" og "(...)/bilde.php?ref=referansenavn" som finner filnavnet internt og presenterer dataene. Med sistnevnte kan du også omskrive alle forespørsler av typen images/*.jpg til å gå innom det scriptet med mod_rewrite. Mye å velge i, altså, men med et stadig økende antall livsfarlige feller å gå i (SQLi, Remote/Local File Inclusion, etc.)

Det viktigste er uansett at det er smertefritt for en bruker å laste opp, finne, og til slutt linke til korrekt bilde. Hvis det er tenkt at enkeltbilder kan deles utenfor siden din, så er det også en fordel at URIen ikke er lang som et uår.
Sikkerhetsklarert
Trådstarter
Jeg har nå valgt å rename filene slik. [yyyy-mm-dd_hh:mm:ss_%anleggID%.jpg]
Siden dette blir et internt CRM/Inventorysystem, så er det bare maks 7-8 brukere. Disse er underlagt hver sine landsdeler, slik at det bare vil være èn person som laster opp bilder til et anlegg. Nå må altså to bilder lastes opp til samme anlegg innenfor samme sekund for å skape trøbbel, det lar seg ikke gjøre.
▼ ... over en måned senere ... ▼
z0p
uʍop ǝpısdn
z0p's Avatar
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.
Sitat av Ueland Vis innlegg
Best practice er å lagre det til disk på den måten som passer best til forskjellige rammeverk/programmeringsspråk, selv etter 10 år har jeg aldri hørt om det du mener er "best practice.".
Vis hele sitatet...
Men picasaweb og G+ har du muligens hørt om?
Sist endret av nudo; 10. februar 2014 kl. 07:45.