[PHP] Bestanden aan records toevoegen

[Xanthium]

Beste Tweakers,

Voor een nieuw project waarmee ik ga beginnen is het nodig dat ik voor elke "record" een mogelijkheid creëer om bijlagen te uploaden en aan dit specifieke record te koppelen. Wat ik wil is dat ik voor elk record uit de MySQL database uit een tabel (noem de tabel "bomen") de mogelijkheid er is om via een webform een bestand aan deze "boom" toe te voegen, bijvoorbeeld een foto van de boom of additionele informatie in een word document.

Een script om files te uploaden naar een directory in de wwwmap is niet zo'n uitdaging, ik kom er alleen niet uit hoe ik de bestanden beheersbaar houdt en koppel aan een specifieke record zodat ze hierbij weer oproepbaar zijn. Is hier een "eenvoudige" oplossing voor?

[Guillome]

$row->ID. ".png"
?

[Xanthium]

Guillome schreef op dinsdag 22 februari 2011 @ 15:51:
$row->ID. ".png"
?

bestand renamen naar de unieke ID van het record?

[Verwijderd]

Niets is echt eenvoudig, maar een redelijk simpele oplossing is de bestanden opslaan in een specifieke folder :

/userefiles/boomfiles/$boom_id/

en daarnaast een reference naar het bestand in een losse table op te slaan, met daarbij natuurlijk de FK naar de boom table.

[Rannasha]

Xanthium schreef op dinsdag 22 februari 2011 @ 16:04:
[...]


bestand renamen naar de unieke ID van het record?

Bijvoorbeeld. Of als je de oorspronkelijke naam van het bestand intact wil houden kun je de naam van het bestand in de database opslaan bij het relevante record.

[_Erikje_]

elke dag/week een nieuwe map aan(laten)maken en de file die geuploadt wordt onder een random naam opslaan in die map. dat scheelt nog al gezeik wanneer je over het maximaal aantal bestanden in een map gaat.

geen blobs gebruiken om je files in op te slaan

[Gomez12]

Wat ik dan weer prefereer is om gewoon een losse files-tabel aan te maken en dan een koppeltabel tussen files-tabel en boom.

Dan kan je ook namelijk ook een simpele implementatie van single storage inbouwen, gewoon zeggen kijken of bestand al bestaat in files tabel zoja dan boom koppelen aan bestaande file anders nieuwe file.

[NMe]

_Erikje_ schreef op dinsdag 22 februari 2011 @ 18:58:
elke dag/week een nieuwe map aan(laten)maken en de file die geuploadt wordt onder een random naam opslaan in die map. dat scheelt nog al gezeik wanneer je over het maximaal aantal bestanden in een map gaat.

Speelt die limiet niet alleen op Windowsservers en zelfs dan alleen bij hele oude versies? En voor gigantische hoeveelheden files in de tienduizenden? Lijkt me nogal een premature optimalisatieslag om per dag een folder te gaan aanmaken.

geen blobs gebruiken om je files in op te slaan

Zelfs dat is best te verdedigen bij kleine thumbnails ofzo. Voor grote foto's zou ik het dan weer niet doen.

[Guillome]

Nadeel bij bestandsnaam intact laten en de filename in de DB opslaan is dat je moet checken op of de afbeelding al bestaat, en dan moeten renamen etc. Is toch weer extra gedoe.
Ik doe het in mijn webshop zo:
Hoofdafbeelding wordt image_$ID.png
En alle extra afbeeldingen worden extra_image_$ID_x.png waarbij x van 1 tot aantal afbeeldingen loopt.

[NMe]

Guillome schreef op dinsdag 22 februari 2011 @ 19:26:
Nadeel bij bestandsnaam intact laten en de filename in de DB opslaan is dat je moet checken op of de afbeelding al bestaat, en dan moeten renamen etc. Is toch weer extra gedoe.

Waarom? Op je filesystem geef je hem gewoon de naam <id>.jpg, en vervolgens regel je gewoon met multiviews/mod_rewrite en de juiste HTTP-headers dat de url <id>/<filename>.jpg ook werkt, eventueel afgehandeld door een PHP-script.

[Guillome]

Dan sla je m alsnog op als $ID.png, en niet als bestandsnaam.png en daar ging het om

[Hipska]

En waarom dan nog .png er achter plaatsen? Als je zoals NMe zegt de afhandeling door php laat doen (headers enzo), dan kan je gewoon images/$ID als bestandsnaam geven.

Dan hoef je ook al niet meer te controleren of het een png of jpg of gif is.

[Reptile209]

NMe schreef op dinsdag 22 februari 2011 @ 19:31:
[...]

Waarom? Op je filesystem geef je hem gewoon de naam <id>.jpg, en vervolgens regel je gewoon met multiviews/mod_rewrite en de juiste HTTP-headers dat de url <id>/<filename>.jpg ook werkt, eventueel afgehandeld door een PHP-script.

Dan loop je er toch tegenaan dat Flierps.jpg niet tweemaal gebruikt mag worden, omdat de multiview/mod_rewrite dan nog steeds niet weet welke je bedoelt?

Als het om grote files gaat met een redelijke kans op dubbele files (binair identiek), kan het nog lonen om ook een MD5-hash oid op te slaan in je DB. Bij gelijke hashes tussen een file die wordt geüpload en een bestaande file, hoef je 'm maar één keer op de server te bewaren (let wel op met delete-mogelijkheden als je meerdere referenties naar dezelfde file kunt hebben).

[Jory]

Totaal afhankelijk van wat je precies aan het doen bent (hoeveel bomen en bestanden, wat je met de bomen, bestanden en de relatie daartussen moet kunnen, etc) maar het zou een optie voor je kunnen zijn om bij het toevoegen van een bestand een record toe te voegen aan een 'bestanden' tabel, waarin je de bestandnaam en eventuele meta-data bijhoud. Die koppel je vervolgens (1:n of n:m, wat jij wil) aan je 'bomen' tabel, en je kunt eenvoudig opzoeken welke bestanden je hebt, wat bij welke boom hoort, eventuele statistieken, etc.

Moet je alleen nog zorgen dat je database en filesystem synchroon blijven.

NMe schreef op dinsdag 22 februari 2011 @ 19:23:
[...]
Speelt die limiet niet alleen op Windowsservers en zelfs dan alleen bij hele oude versies? En voor gigantische hoeveelheden files in de tienduizenden?

Nah, *nix kan daar ook last van hebben. Wij gebruiken tegenwoorden meestal een /(letter 1 van de naam)/(letter 2)/(volledige bestandnaam).ext structuur.
Bij een ouder project, waarbij dat niet is gedaan, gaat putty kapot als je een ls van de verkeerde map doet.

[NMe]

Reptile209 schreef op dinsdag 22 februari 2011 @ 19:48:
[...]

Dan loop je er toch tegenaan dat Flierps.jpg niet tweemaal gebruikt mag worden, omdat de multiview/mod_rewrite dan nog steeds niet weet welke je bedoelt?

Natuurlijk wel, want de bestandsnaam is gewoon <id>, met of zonder extensie. Mod_rewrite zorgt dan wel dat het stuk achter de slash gewoon genegeerd wordt. 1337/Flierps.jpg levert dan dezelfde file op als 1337/foobar.jpg maar een andere image dan 31337/Flierps.jpg.

Hipska schreef op dinsdag 22 februari 2011 @ 19:44:
En waarom dan nog .png er achter plaatsen? Als je zoals NMe zegt de afhandeling door php laat doen (headers enzo), dan kan je gewoon images/$ID als bestandsnaam geven.

Dan hoef je ook al niet meer te controleren of het een png of jpg of gif is.

Dat zou ik alleen doen als je de browser vervolgens wel de illusie geeft een bestand met de juiste extensie te downloaden op de manier die ik hierboven beschrijf.

[ Voor 32% gewijzigd door NMe op 22-02-2011 22:51 ]

[Reptile209]

NMe schreef op dinsdag 22 februari 2011 @ 20:07:
[...]

Natuurlijk wel, want de bestandsnaam is gewoon <id>, met of zonder extensie. Mod_rewrite zorgt dan wel dat het stuk achter de slash gewoon genegeerd wordt. 1337/Flierps.jpg levert dan dezde file op als 1337/foobar.jpg maar een andere image dan 31337/Flierps.jpg.
[...]

Ah, zo. Ik las het als <id> of <filename>, in plaats van <id>/<filename>...
Carry on .

[Guillome]

Hipska schreef op dinsdag 22 februari 2011 @ 19:44:
En waarom dan nog .png er achter plaatsen? Als je zoals NMe zegt de afhandeling door php laat doen (headers enzo), dan kan je gewoon images/$ID als bestandsnaam geven.

Dan hoef je ook al niet meer te controleren of het een png of jpg of gif is.

Omdat je de gebruiker wel wilt laten zien dat het om een afbeelding gaat. Het is smaak. Ik vind het wel mooi om de filename volledig te laten zien. Ik bekijk liever host.nl/images/14/nepfilename.png dan host.nl/images/14
Smaak

[Hipska]

Dan nog kan volgens het principe van NMe het bestand gewoon als images/14 op het filesysteem staan. Ik vind de URL in de browser zoals jij voorstelt ook mooier hoor.

Hoe je een URL served aan de browser/bezoeker heeft niets te maken met hoe het opgeslaan is op het filesysteem.

[NMe]

Hipska schreef op dinsdag 22 februari 2011 @ 23:04:
Dan nog kan volgens het principe van NMe het bestand gewoon als images/14 op het filesysteem staan. Ik vind de URL in de browser zoals jij voorstelt ook mooier hoor.

Sterker nog, dezelfde file zou bereikbaar zijn met images/14/test.jpg als ook met images/14 als ook met images/14/totalerandomshite.

edit:
@hieronder: bastard.

[ Voor 4% gewijzigd door NMe op 22-02-2011 23:43 ]

[Bozozo]

Net als http://tweakers.net/nieuws/72744/tweaker-laat-usb-stick-in-duim-implanteren.html

[ Voor 30% gewijzigd door Bozozo op 22-02-2011 23:15 ]

[Cartman!]

Hou er alleen nog rekening mee dat als het om profielfoto's oid gaat dat je even een hash als naam pakt oid. Anders kan iemand met een simpele for-loop al je foto's eraf rippen

Ik maak meestal voor zoiets een map per x aantal id's, dus user 1 z'n meuk komt bijv. in 000000-000999 terecht, zo komt in dit geval voor elke 1000 users er een nieuwe map.

[Jeffroiscool]

Of je gebruikt in plaats ID een hash die je creeert i.v.m het tijdstip en het zal niet zo simpel meer zijn

Overigens pas op dat je met url-rewrite stuff veel online diensten de screenshot niet door kan linken omdat hij geen extensie ziet staan

[CodeCaster]

Wat dan weer prima is af te vangen met .htaccess door de extensie niet door te linken.