[PHP] Wat is verstandiger? files in DB of FS?

[cappie]

Ik vraag me af wat verstandiger is.. files zoals images in een database opslaan en vervolgens daaruit trekken met behulp van queries (mega flexibel) or gewoon op je filesystem plempen en alleen linkjes naar je files maken (sneller)..

Ik zit er namenlijk aan te denken om een simpele content engine te bouwen (beetje spelen, effe m'n PHP skills oppoetsen) waarmee je ook images kunt uploaden en rescalen bij je articles/content/whatever

Ik weet dat gewoon rauw op je FS beter is qua performance, maar ik weet ook dat je database met linkjes nogal gauw nutteloos is als je per ongeluk een plaatje renamed.

Iemand een (fatsoenlijk) idee?

[raptorix]

Zijn al erg veel topics over geweest, je geeft ook al zelf de antwoorden.

[drm]

cappie:
(...)
ik weet ook dat je database met linkjes nogal gauw nutteloos is als je per ongeluk een plaatje renamed.

Tja, dat moet je dus ook niet toestaan. Ik heb een grote voorkeur voor FS. Vind ik zelf makkelijker onderhoudbaar.

[[ti]]

Eigenschappen van de plaatjes opslaan in je db, plaatjes zelf opslaan op je fs. Je gaat toch niet querien op de inhoud van het plaatje enzo. Vrij nutteloos om dat dus in je db te hebben.

[Verwijderd]

Ik maak gebruik van beide.
Ik upload een image, en ram een ID en omschrijving in een database. Vervolgens vraag ik het betreffende ID op, en verplaats mijn image naar de map /images en hernoem het betreffende bestandje naar $ID.$type ($type is natuurlijk een gif, jpg of png!) vervolgens update ik de database met het betreffende path.
Vervolgens kun je makkelijk fot's opsnorren, en invoeren bij verhalen (simpelweg een path of ID opgeven, en met subqueries uit vogelen hoe en wat).
Performance is okay, geen acterlijk volle databases en de snelheid is bijna optimaal.

[cappie]

'k.. thnx guys.

[drm]

Op maandag 07 januari 2002 14:28 schreef daniel_hoenderdos het volgende:
Ik maak gebruik van beide.
Ik upload een image, en ram een ID en omschrijving in een database. Vervolgens vraag ik het betreffende ID op, en verplaats mijn image naar de map /images en hernoem het betreffende bestandje naar $ID.$type ($type is natuurlijk een gif, jpg of png!) vervolgens update ik de database met het betreffende path.
Vervolgens kun je makkelijk fot's opsnorren, en invoeren bij verhalen (simpelweg een path of ID opgeven, en met subqueries uit vogelen hoe en wat).
Performance is okay, geen acterlijk volle databases en de snelheid is bijna optimaal.

* drm doet het hetzelfde

[ycode]

Ik heb voor m'n afstuderen een project gedaan waarbij een complete website (html, css, images etc) uit de database gehaald werden; alles inclusief een online editor/beheer module. Daarnaast heb ik getest wat het verschil in performance was.

De database versie had een dramatisch slechte performance ! Niet zo verwonderlijk, maar als afstudeeropdracht zeker een keer leuk om te doen...

[Janoz]

Op maandag 07 januari 2002 15:08 schreef drm het volgende:

[..]

* drm doet het hetzelfde

* Janoz niet

Ik kopieer liever eerst het bestand, en dan pas de DB entry.. Als er dan iets fout gaat, dan is er een image die niet in de db voorkomt, en niet een record dat naar een nietbestaand bestand wijst . Image geef ik dan als naam de timestamp + userID (ook redelijk uniek als je eist dat een gebruiker maar 1x ingelogd mag zijn)

[Grum]

ik ben nog steeds ervoor om het plaatje gewoon te noemen naar z'n md5sum (en ja plaatjes hoeven geen extensie te hebben)

[drm]

Grum_:
ik ben nog steeds ervoor om het plaatje gewoon te noemen naar z'n md5sum

Waarom md5

Janoz:
* Janoz niet
Ik kopieer liever eerst het bestand, en dan pas de DB entry..

kan ook, maar je zou dat dan ook kunnen zien als een entry waarvan het plaatje nog geupt moet worden...

Als er dan iets fout gaat, dan is er een image die niet in de db voorkomt, en niet een record dat naar een nietbestaand bestand wijst . Image geef ik dan als naam de timestamp + userID (ook redelijk uniek als je eist dat een gebruiker maar 1x ingelogd mag zijn)

Waarom zou je dat doen, als er in de database toch al een imageID bestaat (uniek)

als de datum van het bestand en userID ook interessant is voor het plaatje, heb je dat ongetwijfeld ook in je db opgenomen, toch

[Grum]

Op dinsdag 08 januari 2002 09:39 schreef drm het volgende:

Waarom md5

Ik had een systeem gemaakt waar je gewoon plaatjes kon uploaden. Om te voorkomen dat men grote series van plaatjes kon 'slurpen' of dat je dubbele plaatjes krijgt (wat bv een tweakers.net geheid heeft) had ik mijn systeem zo gemaakt dat je het plaatje naar z'n md5sum van de data werd gerenamed. Na het renamen alle informatie (originele filename, filesize, h&b, filetype, md5sum, omschrijving, evt thumb-md5) de db ingooien en je kan enorm simpel controleren of een plaatje al bestaat.

Natuurlijk heb je daar een zekere foutmarge maar die is imho dusdanig klein dat ik me daar niet zoveel zorgen over maak. Vind maar es 2 verschillende plaatjes met dezelfde filesize EN de zelfde hash (als je dit toch gaat doen kan je misschien beter 2 verschillende files (geen plaatjes) zoeken met dezelfde filesize & hash .. dat is al bijna onmogelijk )

correct me if i'm wrong (ik ga uit van een perfect md5 algoritme hier .. maar dat zal ie vast niet zijn (man-made he )).

Maar dan zou je pas zeker kunnen zijn van het bestaan van 2 verschillende files met dezelfde size met dezelfde md5hash als ze groter zijn dan 3,4028...e+38 bits (=2^128) = ziekelijk bytes.

Nu is het algoritme natuurlijk niet perfect (zou te mooi zijn ) maar ik vind (en vond) wel dat het een groot genoege zekerheid gaf om dit te gebruiken.

Daarnaast werkt html als [img]f274f5031f97f097c553fcd75a37c4a6[/img] (ja dat is zonder extensie) op genoeg browsers om het ook echt bruikbaar te maken (ik heb het met ~20 browsers op mac/linux/windows geprobeert en geen problemen ondervonden))

Dus daarom

^{[edit]Damn wat een brak nederlands af en toe [/edit]}

[drm]

Grum_ legde even uit waarom hij md5 gebruikte

ach so idd wel handig op die manier, ja...