[PHP] Extra informatie over bestanden in database?

[Reveller]

Gebruikers kunnen bij mijn CMS'je bestanden uploaden in de map files/. In deze map kunnen zij subdirs aanmaken. Als er een bestand wordt geupload, wordt het bestand in het goede mapje op de harde schrijf gezet. Tevens sla ik wat info op in de database, bijvoorbeeld:

code:

+-----+--------------+--------------------+-------------+-------+------------+-----+
| fid | name         | mime               | path        | size  | created    | uid |
+-----+--------------+--------------------+-------------+-------+------------+-----+
|  59 | document.doc | application/msword | files/doc/  | 24576 | 1129144609 |   7 |
+-----+--------------+--------------------+-------------+-------+------------+-----+
|  62 | style.css    | text/css           | files/css/  | 2884  | 1129144568 |  43 |
+-----+--------------+--------------------+-------------+-------+------------+-----+

Dit werkt allemaal perfect. Als een document verwijderd wordt, wordt daarmee ook de betreffende tabelrij verwijderd. Ik ben nu bezig een script te schrijven waarmee de gebruiker door de bestanden kan bladeren (je ziet hier de inhoud van de map files/):


Momenteel genereer ik deze tabel door met een scriptje het filesystem te benaderen en door de map te lopen. Met behulp van de functies filesize en filectime kan ik bijna alle gegevens oproepen. Als ik bovenstaande tabel genereer, gebruik ik de database eigenlijk alleen om de created time erbij te kunnen zetten (ik zie hier geen php functie voor) en om eventueel nog te kunnen laten zien welke user (uid gekoppeld aan user-tabel) het bestand geupload heeft.

Voor zover ik kan zien, is er dus eigenlijk geen nut aan het opslaan van de mimetype, path en size van de bestanden in de database. Die kan ik immers real-time opvragen mbv php functies. Toch zie ik bij veel open-source projecten dat zij wel al die info in de database opslaan. Wat is hiervoor een argument?

Ook maak ik me zorgen om de integriteit van dit systeem. Als een document corrupt raakt of per ongeluk via bv. FTP verwijderd wordt uit de files-map, weet de database niet beter of het bestand bestaat gewoon nog. Ik kan twee dingen doen: de eerste is om via een cronjob (of iets dergelijks) de integriteit te checken en eventueel niet-matchende database rijen verwijderen. De tweede is om het hele database gebeuren te laten vallen en puur op filesystem over te gaan. Ik kan dan bv. niet meer bestanden aan users koppelen, maar of dat nu zo essentieel is...?

Graag hoor ik van jou hoe jij te werk gaat. Sla jij extra info over de bestanden op in de database en zo ja, welke? Wat is jouw argument om wel / niet een combinatie van database en filesystem te maken?

[ Voor 4% gewijzigd door Reveller op 13-10-2005 21:12 . Reden: typo's / layout ]

[Verwijderd]

Reveller schreef op donderdag 13 oktober 2005 @ 21:10:
Voor zover ik kan zien, is er dus eigenlijk geen nut aan het opslaan van de mimetype, path en size van de bestanden in de database.

Het mimetype zie ik je anders niet achterhalen m.b.v. de functies die je noemt? True, je kunt het gokken aan de hand van de extensie (bv. .doc voor word bestanden), maar wat als iemand die verkeerd ingeeft?

De size van een bestand in de database opslaan is alleen nuttig als je webgeval geen fysieke toegang heeft tot de bestanden zelf. De enige reden waarom je het dan toch nog in de DB zou zetten, is performance. Je doet sowieso toch die query, dus waarom niet gelijk de filesize ophalen? Scheelt weer 1 stap in het proces.

[Verwijderd]

Persoonlijk ben ik er voorstander om het document zelf ook in de database te stoppen. Alles staat dan bij elkaar, je bent onafhankelijk van het onderliggende OS en mensen moeten jou software gebruiken om de file te kunnen benaderen.

Maar de discussie bestanden in filesysteem of database is al héél oud. Wel lost het jou integriteitprobleem op

[PrisonerOfPain]

Verwijderd schreef op donderdag 13 oktober 2005 @ 21:14:
True, je kunt het gokken aan de hand van de extensie (bv. .doc voor word bestanden), maar wat als iemand die verkeerd ingeeft?

Dan kijk je met mime_content_type.

[Verwijderd]

Dat is dus gokken adhv. extensie..

[megamuch]

Verwijderd schreef op donderdag 13 oktober 2005 @ 23:18:
Dat is dus gokken adhv. extensie..

Da's niet waar.

PHP:

//checking if file is JPG or not.
function isValidFile($result, $UploadDir)
    {
    $allowed_types = array("image/pjpeg","image/jpeg");
    foreach($result as $value)
        {
        $tempfile = trim($value['tempfile']);
        $filetype = mime_content_type($UploadDir.$tempfile);
        if (in_array($filetype,$allowed_types))
            {
            $validfile = 1;
            }
        else
            {
            $validfile = 0;
            }
        }
        return $validfile;
    }

Als in dit geval $tempfile een text file is met een .jpg extensie dan returned dit toch echt false.

[ Voor 4% gewijzigd door megamuch op 13-10-2005 23:39 ]

[supersook]

Mijn voorkeur gaat eigenlijk toch uit naar een opzet zonder gegevens in de database.

Zo'n web based filebrowser is wat mij betreft nog steeds een frontend voor het normale bestandssysteem (in het geval dat je het ook als bestanden opslaat). Zoals je zelf al aangeeft is bij het gebruik van een DB de kans op fouten groter, doordat je het risico loopt dat er misschien iets is gedelete via FTP oid. Bij gebruik van alleen een filesystem is het ook een voordeel dat je niet gebonden bent aan je eigen frontend, mocht er bijvoorbeeld eens een foutje in sluipen kun je altijd via een andere weg nog corrigeren. Qua performance denk ik dat bij grote listings de DB wel in het voordeel is, maar bij 10 (100?) tallen is er volgens mij geen performanceprobleem bij het realtime ophalen van de gegevens via de filesystem functies.

Er wordt hierboven ook nog gesuggereert om zowel bestanden als de gegevens ervan in een DB op te slaan. Wat mij betreft is dit verkeerd gebruik van technieken. Ok, het werkt prima, maar laat elke schoenmaker maar bij z'n leest blijven, ze zijn ieder uiteraard voor hun eigen taak het best geschikt.

[Gomez12]

Wat mij betreft hangt het er voornamelijk van af of je web-interface de enige is die er toe doet??? Zoja heb je veel dubbel files???

Want ik sla een heleboel bestandsinfo op in de dbase en haal dit weer terug dmv virtual folders.
Voorbeeld elke gast heeft een eigen folder met 1 introductie bestand, maar ik ga toch echt niet fysiek het intro-bestand naar alle gast-folders copieren. Plus dat bij mijn website gebleken is dat er relatief veel dezelfde grote files werden geupload, ook in private spaces. Dus toen uiteindelijk toch maar gekozen voor een virtual fs dat uit de db getrokken wordt, zodat als 3 mensen office2003.iso uploaden ik ze alledrie diff en dan uiteindelijk maar 1 file (indien alle 3 gelijk) fysiek op schijf opsla. De copieeen regel ik wel via een extra entry in de dbase.
Niemand die het merkt want de web-interface is de enige toegangsmogelijkheid.

[ikke007]

Gezien je toch al die query op de database doet kan je het ook andersom doen, adhv de database controleren of alle files die daarin staan ook fysiek aanwezig zijn in je filesystem. Indien dit niet het geval is kan je een onzichtbare error generen voor jezelf dat er een bestand verdwenen is, deze link niet tonen aan de gebruiker en eventueel direct ook deze rij uit je database verwijderen....

[Hydra]

Als je 'alles' behalve de daadwerkelijke file in de DB zet, kun je een mooi vitueel filesysteem creeren dat loststaat van de daadwerkelijke DB. Je zou bijvoorbeeld alle bestanden in dezelfde directory op kunnen slaan (ik ben geen voorstander van de file als blob in de DB zetten trouwens), met als bestandsnaam gewoon de ID, en in je DB/systeem zelf een filesysteem met rechten, directories en virtuele kopieen e.d. kunnen creeren.

Als je gewoon een simpel filefrontend wil hebben, kun je net zo goed die hele DB niet gebruiken, helemaal als je itereered over de files i.p.v. die lijsten uit de DB te halen.

[Verwijderd]

supersook schreef op donderdag 13 oktober 2005 @ 23:55:
Er wordt hierboven ook nog gesuggereert om zowel bestanden als de gegevens ervan in een DB op te slaan. Wat mij betreft is dit verkeerd gebruik van technieken. Ok, het werkt prima, maar laat elke schoenmaker maar bij z'n leest blijven, ze zijn ieder uiteraard voor hun eigen taak het best geschikt.

Vandaar dat Microsoft al jaren probeert om het filesysteem van windows te vervangen door een database. WinFS iemand

Zo groot zijn de verschillen tussen een filesysteem en een database namelijk ook weer niet. Maar het voordeel van een database is dat je via meerder zoekpaden bij dezelfde data kan komen. Het filesysteem ondersteund maar 1 zoekpad.

Verkeerd gebruik van technieken vind ik de mengvormen die ontstaan door wel een database te gebruiken maar ook een filesysteem. Die zijn niet portable en je bent heel veel zaken dubbel aan het opslaan. In mijn ogen moet je óf kiezen voor een filesysteem óf kiezen voor een database, maar beide zaken door elkaar heen gebruiken levert in mijn ervaring alleen maar problemen op.

[Reveller]

Bedankt voor de goede reakties tot nu toe Ik moet zeggen dat ik er nog niet helemaal uit ben. iKKe007 heeft gelijk als hij zegt dat je de data integriteit ook zelf kunt bewaken:

iKKe007 schreef op vrijdag 14 oktober 2005 @ 09:20:
Gezien je toch al die query op de database doet kan je het ook andersom doen, adhv de database controleren of alle files die daarin staan ook fysiek aanwezig zijn in je filesystem. Indien dit niet het geval is kan je een onzichtbare error generen voor jezelf dat er een bestand verdwenen is, deze link niet tonen aan de gebruiker en eventueel direct ook deze rij uit je database verwijderen....

Op die manier kun je het probleem wat Jan Klaassen ziet (en die ik ook zag), ondervangen:

Verwijderd schreef op vrijdag 14 oktober 2005 @ 12:26:
[...] In mijn ogen moet je óf kiezen voor een filesysteem óf kiezen voor een database, maar beide zaken door elkaar heen gebruiken levert in mijn ervaring alleen maar problemen op.

Feit is dat ik toch wel graag bestanden koppel aan users en dat ik ook graag de datum/tijd opsla waarop het bestand geupload is. Ik heb dus wel een database nodig om deze data in op te slaan. Daarnaast heeft werken met een database andere (flexibile) voordelen, zoals

Gomez12 schreef op vrijdag 14 oktober 2005 @ 00:47:
[...] Want ik sla een heleboel bestandsinfo op in de dbase en haal dit weer terug dmv virtual folders.
Voorbeeld elke gast heeft een eigen folder met 1 introductie bestand, maar ik ga toch echt niet fysiek het intro-bestand naar alle gast-folders copieren.

Dan is de discussie: bestanden zelf (als BLOB) in de database of niet? Ik hoop dat iemand een antwoord / mening kan geven over de volgende zaken:

• Het nadeel van bestanden fysiek op het filesystem op te slaan, is volgens mij dat je er bijna geen toegangsrechten aan kunt toekennen. Binnen mijn CMS kan de beheerder bij elke pagina aangeven welke gebruikersgroepen toegang tot die pagina hebben. Op dezelfde manier zou een beheerder de gebruikersgroepen moeten kunnen aankruisen voor wie een bepaald Worddocument te downloaden is. Staat het bestand in de database, dan lees ik de groep uit waar de huidige gebruiker toe behoort, en dan kan ik vervolgens makkelijk wel / geen toegang geven tot die data uit de database. Dit is bijna onmogelijk als het document in een website.com/files/docs/document.doc folder staat. Als je naar de goede URL surft, kun je het document downloaden. Immers: de rechten van de gebruikers van mijn CMS staat in een mysql database en worden meegenomen in een sessie. De toegang tot bepaalde folders / documenten wordt op een apache server geregeld met .htaccess bestanden, en het is natuurlijk niet te doen om die dynamisch te gaan genereren ofzo om een bezoeker wel / geen toegnag te geven tot document.doc.
• Ik maak gebruik van PHPMyAdmin voor het database onderhoud en backup. Als service naar mijn klanten toe maak ik elke maand een backup van hun database, maar dit gaat waarschijnlijk niet meer via PHPMyAdmin als de documenten in de database staan. Hoe maak je in dat geval een database backup?

[aex351]

Ik heb ook zo'n soort file systeem gemaakt

tabel : bestanden
tabel : mappen

en op de server worden map aangemaakt begint met userid/ tabel mappen / enz

[ripexx]

Reveller schreef op zaterdag 15 oktober 2005 @ 15:45:
[...]
Dan is de discussie: bestanden zelf (als BLOB) in de database of niet? Ik hoop dat iemand een antwoord / mening kan geven over de volgende zaken:
[list]• Het nadeel van bestanden fysiek op het filesystem op te slaan, is volgens mij dat je er bijna geen toegangsrechten aan kunt toekennen. Binnen mijn CMS kan de beheerder bij elke pagina aangeven welke gebruikersgroepen toegang tot die pagina hebben. Op dezelfde manier zou een beheerder de gebruikersgroepen moeten kunnen aankruisen voor wie een bepaald Worddocument te downloaden is. Staat het bestand in de database, dan lees ik de groep uit waar de huidige gebruiker toe behoort, en dan kan ik vervolgens makkelijk wel / geen toegang geven tot die data uit de database. Dit is bijna onmogelijk als het document in een website.com/files/docs/document.doc folder staat. Als je naar de goede URL surft, kun je het document downloaden. Immers: de rechten van de gebruikers van mijn CMS staat in een mysql database en worden meegenomen in een sessie. De toegang tot bepaalde folders / documenten wordt op een apache server geregeld met .htaccess bestanden, en het is natuurlijk niet te doen om die dynamisch te gaan genereren ofzo om een bezoeker wel / geen toegnag te geven tot document.doc.

Als je de files buiten de webroot plaatst kan je ze niet meer bereiken via de webserver en kan je de fles opslaan op de server. De output kan je checken op rechten. Je kan het zo dynamisch maken als je zelf wil.

• Ik maak gebruik van PHPMyAdmin voor het database onderhoud en backup. Als service naar mijn klanten toe maak ik elke maand een backup van hun database, maar dit gaat waarschijnlijk niet meer via PHPMyAdmin als de documenten in de database staan. Hoe maak je in dat geval een database backup?[/list]

Tja, zo moeilijk is het niet om een backup te maken. Maar als je gebruik maakt van BLOB veleden is het wellicht handiger dat je switched naar mysqldump, kan je vaak gewoon via PHP aanroepen en dan de output tarren of zo. Een paar jaar geleden heb ik al eens zo'n script gemaakt. Die desgewenst de dump kan mailen en of ftp naar een andere server.

Verder heeft er niet zo lang geleden een topic gelopen waar ook deze discussie heeft plaats gevonden. Komt dit topic je niet bekend voor: [rml][ ALG] Hoe implementeer ik een mappen-systeem?[/rml]

[ Voor 3% gewijzigd door ripexx op 15-10-2005 16:13 ]

[Reveller]

ripexx schreef op zaterdag 15 oktober 2005 @ 16:08:
[...]
Als je de files buiten de webroot plaatst kan je ze niet meer bereiken via de webserver en kan je de fles opslaan op de server. De output kan je checken op rechten. Je kan het zo dynamisch maken als je zelf wil.

Het punt is dit: ik wil gebruikers van mijn cms de mogelijkheid geven om zelf css, js, swf-bestanden etc. te kunnen uploaden. Die bestanden moeten vervolgens makkelijk in bv. templates te gebruiken zijn. En omdat er geen echte reden is om rechten toe te kennen aan elk css of js bestandje, is het voor die type bestanden niet nodig daar een zwaar privilege systeem omheen te bouwen. Zoals aangegeven in de openingspost, uploadt een gebruiker style.css naar bv. de fysieke map site.com/files/css/style.css voor verder gebruik.

Zoals ik het nu zie, zou ik dus het beste buiten de webroot een map "beveiligde documenten" kunnen maken, waar permissie-based bestanden in komen te staan. Uiteindelijk ben ik maar afgestapt van het idee om bestanden in een database te stoppen. Ik vind dat je OF alle bestanden in fysieke mappen moet plaatsen OF in een database. En ik zie er het nut niet van in om alle plaatjes, js'jes en css'jes te gaan serven vanuit een database. Dus in het kader van consistentie dan ook de beveiligde bestanden maar in een fysieke map ipv database. Of heeft iemand hier een andere mening over? Misschien is het ook een idee om te zeggen "alleen beveiligde bestanden komen uit de database"?

Voor het geval bestanden van buiten de webroot geserveerd worden -- heeft iemand een link naar een voorbeeld code / applicatie? Ik heb nog niet eerder zoiets gemaakt. Ik stel me het volgende voor (pseudo):

1. Klik <a href="beveiligd.php?id=59>hier</a> om het geheime worddoc te downloaden.
2. Controleer privileges van de gebruiker en match deze met de rechten op document 59 (staan in de database)
3. Als rechten niet OK zijn, retourneer een "u heeft geen toegang tot dit document" pagina
4. Als de rechten OK zijn, serveer het bestand. Vraag: HOE?! Hoe zorg ik dat een geauthorizeerd iemand van buiten de webroot een document kan downloaden?