foto's opslaan
Wat is de juiste methode om foto's up te loaden vanaf eenw ebsite als je php en MySQL gebruikt ?
Neem aan dat het niet handig is om ze in je sql database op te slaan....
Neem aan dat het niet handig is om ze in je sql database op te slaan....
De beste methode om foto's te uplaoden is met move_uploaded_file, en vervolgens controleer op de laatste extentie, en mimetypes of het bestand correct is. Verder kan je met getimagesize bij afbeeldingen controleren of het ook daadwerkelijk een afbeelding is.
In de database sla je uiteindelijk alleen de relatieve bestandsnaam van de foto op.
In de database sla je uiteindelijk alleen de relatieve bestandsnaam van de foto op.
Gewijzigd op 08/02/2016 15:22:11 door - Ariën -
De beste methode is om ze op te slaan in de database. Het is wat complex maar het is veel consistenter dan opslaan op schijf. Het voordeel van alles in de database is de database backup. Je hebt alles bij elkaar in een consistent geheel en je hoeft je niet druk te maken over het opslaan van paden, relatieve paden, verhuizen naar een andere server of disk etcetera. MySQL kan het prima ondersteunen. Op het werk doen we niet anders, alles in de database, niks op schijf. Er worden wel wat eisen gesteld aan de configuratie en performance maar dat verdiend zich terug in gemak.
@John
Ik hoor ook wel berichten dat je database daar een stukje trager van wordt? Is dit dan weer zo een onderwerp waar voor en tegenstanders elkaar proberen te overtuigen terwijl beiden methodes misschien wel voor en nadelen bieden? Kun jij hierover iets zeggen en wat zijn de ervaringen van anderen? Zijn er zaken waarmee je rekening moet houden bij het inrichten van de database? Het lijkt me wel een interessant onderwerp. ik zet de bestanden zelf altijd in een upload directory onder een gehashte timestamp + originele extensie en vervolgens zet ik de filenaam in de database. Het pad naar de upload directory schrijf ik weg als configuratie variabele.
Ik hoor ook wel berichten dat je database daar een stukje trager van wordt? Is dit dan weer zo een onderwerp waar voor en tegenstanders elkaar proberen te overtuigen terwijl beiden methodes misschien wel voor en nadelen bieden? Kun jij hierover iets zeggen en wat zijn de ervaringen van anderen? Zijn er zaken waarmee je rekening moet houden bij het inrichten van de database? Het lijkt me wel een interessant onderwerp. ik zet de bestanden zelf altijd in een upload directory onder een gehashte timestamp + originele extensie en vervolgens zet ik de filenaam in de database. Het pad naar de upload directory schrijf ik weg als configuratie variabele.
Gewijzigd op 08/02/2016 16:58:11 door Frank Nietbelangrijk
Het nadeel van alles in de database is ook meteen de database backup. Vooral als de database groeit door het alles maar in je database te dumpen kan dit tot meer zorgen leiden dan het je oplevert. Ook moet je als je alles in je database stopt veel meer roundtrips naar de database doen, wat ook niet altijd even prettig is. Daarnaast zijn bestanden vaak niet relationeel, dus hebben ze niets te zoeken in een relationele database. Maar dan ga je richting database purisme, en dat is ook niet altijd zinnig.
- Ariën - op 08/02/2016 15:13:39:
De beste methode om foto's te uplaoden is met move_uploaded_file, en vervolgens controleer op de laatste extentie, en mimetypes of het bestand correct is. Verder kan je met getimagesize bij afbeeldingen controleren of het ook daadwerkelijk een afbeelding is.
In de database sla je uiteindelijk alleen de relatieve bestandsnaam van de foto op.
In de database sla je uiteindelijk alleen de relatieve bestandsnaam van de foto op.
Dat is niet "de beste methode", maar dat (move_uploaded_file) is een van de te doorlopen stappen als je bestanden wilt uploaden. Als je een geupload bestand niet op de uiteindelijk bestemde plek zet door middel van move_uploaded_file, zal deze bestand -die zich in beginsel in een soort van "limbo" bevindt- aan het einde van het script opgeschoond worden.
De volgorde lijkt mij trouwens ook niet goed. Eerst onderwerp je het bestand aan controles, en dan verplaats je het pas.
Ook hoef je de verwijzing naar het bestand niet te laten plaatsvinden via de (oorspronkelijke) bestandsnaam. Dit is een ontwerpbeslissing en hangt af van je applicatie. Je zou het bestand ook kunnen hernoemen naar het auto-increment id van het bijbehorende record, en in dat record de oorspronkelijke bestandsnaam onthouden, om maar een dwarsstraat te noemen.
Het in de database opslaan van afbeeldingen is niet per definitie goed of fout. Dit hangt van je applicatie af. Er is geen "beste" manier. Als je aangeeft wat je met deze afbeeldingen wilt doen of hoe je deze gebruikt zouden we je kunnen hebben met het vormen van een verstandig besluit die naar alle waarschijnlijkheid het beste in jouw specifieke geval zal uitpakken.
Dit is zoiets als vragen "wat is de beste auto". Elk advies is even zinnig (of zinloos) totdat je weet hoe je de auto gaat gebruiken.
bedankt voor de reacties zover ! Supert!
De bedoeling is een soort marktplaats opzet. Dus artikelen met diverse foto's...
De bedoeling is een soort marktplaats opzet. Dus artikelen met diverse foto's...
Gebruik http://wideimage.sourceforge.net/ kan je leuke dingen mee doen.
De uitleg staat er ook en als je echt problemen hebt kan je de ontwerper nog een mailtje sturen ook.
Natuurlijk moet je wel nog de databank nog in orde maken maar de de commentaar van Thomas wat betreft de auto-increment id is een goede methode anders zit de kans erin dat ge afbeeldingen gaat overschrijven.
De uitleg staat er ook en als je echt problemen hebt kan je de ontwerper nog een mailtje sturen ook.
Natuurlijk moet je wel nog de databank nog in orde maken maar de de commentaar van Thomas wat betreft de auto-increment id is een goede methode anders zit de kans erin dat ge afbeeldingen gaat overschrijven.
@Ben: Ik ben zo'n database purist en ik werk beroepsmatig met relationele database systemen waarbij de grootste database 12Tb is. Maar ook in het klein adviseer ik om alles in de database te bewaren om meerdere redenen. Gemak, alles op 1 plek, geen administratie (zie Frank: upload directory onder een gehashte timestamp + originele extensie en vervolgens zet ik de filenaam in de database. Het pad naar de upload directory schrijf ik weg als configuratie variabele.) Allemaal onnodig programmeerwerk. EN ja, je moet wel energie steken om de database goed te laten performen en als ik zie dat veel php-ers hele tabellen ophalen en in php het juiste record zoeken in een array begrijp ik best dat de keuze eerder voor filesystemen gemaakt wordt. Ikzelf zou dat nooit doen. Alles wat je met SQL kan oplossen is winst. Helaas verdiept menigeen zich niet in de internals van MySQL.
Gewijzigd op 09/02/2016 14:12:35 door John D
Ik gebruik niet eens MySQL, dat is gewoon niet betrouwbaar genoeg. Als je dus daadwerkelijk een "purist" bent ga je niet eens over MySQL beginnen. Overigens heb je het over compleet verschillende doelen. De database zet je in voor waar de database goed in is, het filesystem voor waar het filesystem goed in is. Er komt veel meer bij kijken dan "dit vind ik makkelijk", er is altijd een kosten/baten analyse die daaraan vooraf gaat en dat zou je naar eigen zeggen dus ook moeten weten.
Toevoeging op 09/02/2016 14:20:46:
Overigens heeft niemand wat aan grootspraak.
Toevoeging op 09/02/2016 14:20:46:
Overigens heeft niemand wat aan grootspraak.
Het hangt er ook vanaf hoe je deze foto's klassificeert: is dit data, of toch meer content? Je zou code, data en content prima apart kunnen behandelen. Code en content zouden in aparte "roots" moeten staan, dan is de scheiding tussen deze twee al bijna rond.
Ook zou je het gebruik en onderhoud in ogenschouw kunnen nemen: wat is hier fijn bij? Als je alles in je database propt en vaak een kopie nodig hebt of veelvuldig backups draait kun je wellicht de foto's beter buiten je database houden? Anders kun je niet "even een backup terughalen".
Het hele ontwerp zou in dienst moeten staan van de aard van en omgang met de applicatie. Dit omdraaien waarbij je een soort van universele implementatie neemt en deze toepast op je applicatie is het paard achter de wagen spannen.
Ook zou je het gebruik en onderhoud in ogenschouw kunnen nemen: wat is hier fijn bij? Als je alles in je database propt en vaak een kopie nodig hebt of veelvuldig backups draait kun je wellicht de foto's beter buiten je database houden? Anders kun je niet "even een backup terughalen".
Het hele ontwerp zou in dienst moeten staan van de aard van en omgang met de applicatie. Dit omdraaien waarbij je een soort van universele implementatie neemt en deze toepast op je applicatie is het paard achter de wagen spannen.
En dat is mijn punt ook, het is afhankelijk van je toepassing. Het is niet een kwestie van "dit vind ik makkelijk", maar een kwestie van "wat heb ik nodig".
Ik gebruik altijd de class.upload van Verot, zeer compleet om bestanden te uploaden en te converteren, opslaan in een database, watermerken, vergroten/verkleien enz..
php_class_upload
php_class_upload




