ik ben bezig met een login systeem waar je onder andere een profielfoto kunt uploaden, ik heb verschillende methodes gezocht om dit te kunnen maken en zo kwam ik erachter dat het in principe mogelijk is om de foto te uploaden naar mijn mysql database, maar dat dit niet aan te raden is omdat de website dan slomer wordt. ik vond ook een manier waardoor de bestanden in een map op je server worden opgeslagen, enigste waar ik nu tegen aanloop is hoe kan ik zorgen dat elke foto die geupload wordt aan het juiste profiel wordt gelinkt door middel van de database dus dat er in de database bijv. staat profiel1.jpg onder het kopje foto en dan als ik het profiel wil laden er word gezocht naar profiel1.jpg en de foto wordt getoond
Opslaan op het file-system in een map is inderdaad het beste. Je kan dan ook heel makkelijk de foto's bijvoorbeeld opslaan op een aparte locatie.
Om op je vraag terug te komen. Je kan in de database prima de koppeling leggen tussen foto en profielID.
Gewoon een extra tabel in de database met fotos en daarin de de ID (PK;Auto incr.), filename, profileID.
Of in de db gewoon een flag has_avatar ja/nee bij iemand zijn profiel.
Indien ja > hoest gewoon /images/avatar/<user id>.jpg (of png) of wat dan ook op.
Indien nee > toon standaard "geen profielfoto" afbeelding.
Hangt natuurlijk af van hoe e.e.a. georganiseerd is maar het lijkt mij niet echt nodig om hier op voorhand een aparte tabel voor te introduceren.
Ik lees toch echt een profielfoto, en geen avatar. ;-)
Als het om foto's in een profiel gaat, zou het in mijn gedachte logisch zijn als men meerdere foto's kon uploaden. Vandaar mijn idee voor een aparte tabel. Maar goed, het ligt er echt aan wat je uiteindelijk wilt doen. En of iemand ook meerdere mag uploaden.
iedereen mag maar 1 profielfoto tegelijk uploaden dus ik denk dat het dan het handigst is om te doen hoe thomas hierboven vermeld mocht het zo lukken alvast bedankt
Ik weet niet hoeveel gebruikers je verwacht, maar als dat er "een paar duizend" worden is het misschien handig om nu al aan een gelaagde structuur te denken. Linux doet niet zo heel moeilijk, maar op het moment dat je gaat FTP-en of zoiets is het meestal wel "fijn" als je niet al teveel bestanden in een map hebt. Je kunt dat op meerdere manier doen (voorbeeld: max 1000 foto's per map, het gaat om foto 2015.png):
- /foto/2/15.png
- /foto/2/2015.png
- /foto/002/015.png
- /foto/002/002015.png
- ...
Bij mij gaat het om niet zoveel foto's. Eveneens profiel. Ik gebruik gewoon als naam het id. Geen extra tabel nodig op deze manier. de foto's staan wel buiten de root
Ik lees toch echt een profielfoto, en geen avatar. ;-)
Potato, potahto.
EDIT: omdat profielfoto's waarschijnlijk erg vaak gaan terugkomen als content en het onderdeel is van de identiteit van een persoon loont het waarschijnlijk de moeite om dit apart te behandelen, los van standaard media in (andere) content. De controles om te bepalen of iemand een foto/avatar heeft moeten redelijk "lichtgewicht" zijn, je wilt niet elke keer dat je een (potentiële) profielfoto ophoest een file_exists() uitvoeren omdat dat een knetterdure operatie is. Beter is dan om die informatie in te bakken in profieldata met een simpele flag, en de bestandsnamen voor deze profielfoto's te standaardiseren.
Daarmee ontlast je de database met lastige vragen maar zit het inbegrepen in het ophalen van standaard profielinformatie en ontlast je het filesysteem door deze niet ook allerlei vragen te stellen over het aan- of afwezig zijn van bestanden.
Deze ontwerpbeslissing zorgt dus voor een efficiënte omgang met iets wat waarschijnlijk zeer vaak gebruikt gaat worden.
