[PHP] Bestand uit formulier opslaan in MySQL Blob *

[Dark Wanderer]

Hallo iedereen,

Ik ben een script aan het maken dat we voor school documentjes kunnen opslaan, maar dit werkt niet. Ik wil de bestanden opslaan in de mysql database zelf, in een mediumblob veld.

Ik krijg dit maar niet voor elkaar, ik heb een file veld in mijn formulier gemaakt (nee ik ben dat met enctype niet vergeten , en het veld voor het bestand heet 'bestand'), en nu wil ik het dus in de database opslaan met deze code.

PHP:

//connecten met de database doe ik ergens anders in de php file, dit loopt verder prima

$tmpName  = $_FILES['bestand']['tmp_name'];
$fp      = fopen($tmpName, 'r');
$data = fread($fp, filesize($tmpName));
$data = addslashes($data);
fclose($fp);

                    
            
$str_auteur         = addslashes(htmlspecialchars($_POST['auteur']));
$str_titel          = addslashes(htmlspecialchars($_POST['titel']));
$str_omschrijving   = addslashes(htmlspecialchars($_POST['omschrijving']));
$str_size           = $_FILES['bestand']['size'];
$str_filename       = $_FILES['bestand']['name'];
$str_tijd           = time();

mysql_query("
INSERT INTO documenten
(tijd,auteur,omschrijving,size,titel,filename,approved,data) VALUES
('$str_tijd','$str_auteur','$str_omschrijving','$str_size','$str_titel','$str_filename','n','$data')
");

Ik krijg na het uitvoeren van deze code geen error, en alle velden worden keurig weggeschreven in de database, alleen blijft de blob volgens phpmyadmin leeg (0 bytes).

Wat doe ik in vredesnaam verkeerd?

[sky-]

Bestanden _nooit_ in de database opslaan.

Een verwijzing naar kan wel (dus de positie van de file).
Sla het bestand dus gewoon op de server op.

[Priet]

Mijn gok is: géén addslashes op $data, aangezien dit binaire data is

[McKaamos]

k8skaaay schreef op dinsdag 12 september 2006 @ 09:03:
Bestanden _nooit_ in de database opslaan.

Een verwijzing naar kan wel (dus de positie van de file).
Sla het bestand dus gewoon op de server op.

Was dat nou voor onzin dan?
Ik doe het ook regelmatig. Werkt goed hoor. No problem.

Maargoed, to the subject: Probeer eens niet te addslashen.\

edit: nog ff bij php.net gekeken. probeer eens de optie "rb" ipv "r" op te geven bij fopen().

[ Voor 10% gewijzigd door McKaamos op 12-09-2006 09:16 ]

[TafkaT]

PHP:

$str_filename        = ADDSLASHES($_FILES['bestand']['name']);

En wat is de error?

[ Voor 124% gewijzigd door TafkaT op 12-09-2006 09:19 ]

[sky-]

McKaamos schreef op dinsdag 12 september 2006 @ 09:14:
[...]


Was dat nou voor onzin dan?
Ik doe het ook regelmatig. Werkt goed hoor. No problem.

Maargoed, to the subject: Probeer eens niet te addslashen.\

edit: nog ff bij php.net gekeken. probeer eens de optie "rb" ipv "r" op te geven bij fopen().

http://phpfreakz.nl/forum.php?forum=2&iid=884187

Lees het daar maar eens, de TS heeft daar zijn vraag ook al gesteld en daar noemt Corne Dickens het antwoord , om maar even te quoten :

" Afbeeldingen/binaire bestanden in je database moet je gewoon niet aan beginnen, Vincent had hier een mooi artikel over maar aangezien zijn server plat ligt: het komt erop neer dat voor elk bestand er een nieuwe connectie gemaakt moet worden waarbij dat geheugen dus op de server verbruikt wordt + nog de overhead van MySQL.
Dubbele bestanden kun je veel beter voorkomen door de bestanden zelf een naam te geven. Je zou de originele naam dan nog in de database kunnen zetten (als je die wil bewaren).

voorbeeld
Bestanden:
1.jpg
2.jpg
3.jpg

database:
id | ext | naam
1 | jpg| pietje
2 | jpg| karel
3 | jpg| anderbestand "

Dus ga aub niet zeggen dat het onzin is. Ga maar eens meer phpen met meerdere mysql querys naast elkaar, dan let je dus echt wel op de preformance hoor. En om dan elk bestand uit je database te moeten gaan vissen..

dan heb ik het ook nog niet over mysql-injections.. Die dus gewoon je data kunnen beschadigen door simpel een tekentje te verwijderen, dit is wat minimaler bij gewoon data opslaan.

[ Voor 14% gewijzigd door sky- op 12-09-2006 09:25 ]

[Rowdy.nl]

Ik doe dit, werkt als een tiet...
(bin_data is mijn blob)

PHP:

if(isset($_FILES['picture']) && ($_FILES['picture']['size'] > 0))
{
    $data = addslashes(fread(fopen($_FILES['picture']['tmp_name'], "r+"), filesize($_FILES['picture']['tmp_name'])));
    $sql = "INSERT INTO binary_data (description, bin_data, filename, filesize, filetype) ".
                "VALUES ('".$_POST['title']."','".$data."','".$_FILES['picture']['name']."','".$_FILES['picture']['size']."','".$_FILES['picture']['type']."')";
        mysql_query($sql, $this->db->get_link()) or header("Location: admin.php?show=error&id=20");
        $id = mysql_insert_id();
     }

[TafkaT]

k8skaaay schreef op dinsdag 12 september 2006 @ 09:22:
[...]

Dat is op dit moment toch niet de vraag? Of het verstandig is of niet, hij vraagt om een oplossing voor een probleem.

[sky-]

TafkaT schreef op dinsdag 12 september 2006 @ 09:24:
[...]

Dat is op dit moment toch niet de vraag? Of het verstandig is of niet, hij vraagt om een oplossing voor een probleem.

Dit klopt, maar ik geef gewoon _het beste_ voorbeeld terug, het is gewoon beter om geen data op te slaan in een mysql veld.

[Rowdy.nl]

TafkaT schreef op dinsdag 12 september 2006 @ 09:24:
[...]

Dat is op dit moment toch niet de vraag? Of het verstandig is of niet, hij vraagt om een oplossing voor een probleem.

Ben ik het mee eens. En het is ook maar de vraag waar TS het voor gebruikt. Als het een paginaje met wat foto's voor privegebruik binnen de familie is, prima toch? Is het echter een site die veel bezoekers gaat trekken, dan kun je er misschien over denken om het niet te doen...

[CodeCaster]

Even offtopic, ik ben het eens met k8skaaay. Het bestandssysteem is voor bestanden, je database is voor informatie. Even een paar links:

http://databases.aspfaq.c...se-or-the-filesystem.html (ASP en MSSQL)
\[Databases/ASP] Images in database op HD opslaan


[/offtopic]

[Janoz]

@k8skaaay: Een hobbyistenclubje als phpfreakz noem ik nu niet een authoriteit op het gebied van ontwikkelkeuzes, en de artikelen van die Vincent heb ik ook niet een al te hoge pet op (lees alleen al zijn reguliere expressie artikel. Dit barts van de fouten)

Er is niet stellig te zeggen dat je bestanden nooit in een db op moet slaan. Er zijn vele redenen om dit niet te doen, maar ook vele redenen om dit juist wel te doen. De keuze zal je af moeten hangen van de omstandigheden.

@codecaster: Een bestand is toch ook informatie?

Leuk leesvoer over dit onderwerp : [ALG] Hoe implementeer ik een mappen-systeem?


@TS: Je leest binairy bestanden in (als in niet tekst bestand). Misschien helpt het wanneer je neit "r", maar "rb" gebruikt bij fopen?

[ Voor 13% gewijzigd door Janoz op 12-09-2006 09:38 ]

[TafkaT]

Ok, nog 1 post:
http://www.oracle.com/tec...y_images_in_database.html
Een artikel van een iets grotere autoriteit op dit gebied.

En ontopic: wat is nu de foutmelding?
(en wat was de bestandsnaam, zie mijn vorige post)

[sky-]

Janoz schreef op dinsdag 12 september 2006 @ 09:33:
@k8skaaay: Een hobbyistenclubje als phpfreakz noem ik nu niet een authoriteit op het gebied van ontwikkelkeuzes, en de artikelen van die Vincent heb ik ook niet een al te hoge pet op (lees alleen al zijn reguliere expressie artikel. Dit barts van de fouten)

Er is niet stellig te zeggen dat je bestanden nooit in een db op moet slaan. Er zijn vele redenen om dit niet te doen, maar ook vele redenen om dit juist wel te doen. De keuze zal je af moeten hangen van de omstandigheden.

@codecaster: Een bestand is toch ook informatie?

Leuk leesvoer over dit onderwerp : [ALG] Hoe implementeer ik een mappen-systeem?


@TS: Je leest binairy bestanden in (als in niet tekst bestand). Misschien helpt het wanneer je neit "r", maar "rb" gebruikt bij fopen?

Ach er zijn nog genoeg communities die het zelfde beweren.

Ik weet niet waar jij allemaal actief bent, maar vraag het daar maar eens. 9 van de 10 maal wordt het bestand opslaan op de server tóch wel aangegeven, zoniet dan is het iemand die het helemaal fout aanpakt.


ps. Hobbyisten club? Zijn dat niet al die websites.. Sorry hoor

[ Voor 3% gewijzigd door sky- op 12-09-2006 09:43 ]

[ReseTTim]

k8skaaay schreef op dinsdag 12 september 2006 @ 09:42:
ps. Hobbyisten club? Zijn dat niet al die websites.. Sorry hoor

jaja incl. t.net / got
btw ik hanteer ook de FS methode, ffies gelezen de wat en waarom en is opzich wel interessant.

wat dus eigenlijk beweert wordt in een eerder artikel dat hier staat is dat FS en DB ong. even snel cq DB sneller is. daarnaast veiliger, beheerbaarder en voor backups ideaal.

mmh misschien die van mij toch ook ooit maar is omzetten.

enige grote nadeel is dat als het bestand in de DB staat is dat je hem niet ffies snel kan bekijken..

[Janoz]

k8skaaay schreef op dinsdag 12 september 2006 @ 09:42:
[...]

Ach er zijn nog genoeg communities die het zelfde beweren.

Ja, en er zijn daar tegenover ook artikelen en communities die wat anders beweren. Waarom? Omdat deze vraag geen absoluut antwoord heeft. Je kunt niet zegen dat oplossing A altijd de juiste keuze is.

Ik weet niet waar jij allemaal actief bent, maar vraag het daar maar eens. 9 van de 10 maal wordt het bestand opslaan op de server tóch wel aangegeven, zoniet dan is het iemand die het helemaal fout aanpakt.

Ik ben actief in verschillende omgevingen waarbij bij de meesten de data integriteit belangrijker is dan de kleine performance impact. Hierbij valt te denken aan overheidsinstellingen met 10.000-en klanten en grote mondiale organisaties met een wereldwijd netwerk tot kleine losstaande instellingen met enkele tientallen gebruikers. Meerdere keren ben ik hierbij tegen het 'DB of FS' vraagstuk aangelopen en de oplossing is toch vaak verschillend afhankelijk van de gewenste randvoorwaarden.

ps. Hobbyisten club? Zijn dat niet al die websites.. Sorry hoor

Nee, sommige artikel worden nu eenmaal geschreven door mensen die leuk hobbyen en sommige artikelen worden nu eenmaal geschreven die professioneel bezig zijn (als in, het is hun werk). Sommige van die artikelen zijn erg interessant en sommigen zijn onzin. Alle artikelen zul je sowieso met een zekere vorm van scepsis moeten lezen. Als iets in een artikel staat betekent dit nog niet dat het de absolute waarheid is.

[NMe]

Janoz schreef op dinsdag 12 september 2006 @ 10:03:
Nee, sommige artikel worden nu eenmaal geschreven door mensen die leuk hobbyen en sommige artikelen worden nu eenmaal geschreven die professioneel bezig zijn (als in, het is hun werk). Sommige van die artikelen zijn erg interessant en sommigen zijn onzin. Alle artikelen zul je sowieso met een zekere vorm van scepsis moeten lezen. Als iets in een artikel staat betekent dit nog niet dat het de absolute waarheid is.

offtopic:
Puur omdat die ruis erin zit weer ik die site al sinds jaar en dag. Artikelen van prutsers en pro's staan kriskras door elkaar, en bovendien worden achterhaalde artikelen niet eens verwijderd. Er staan beginnerstutorials op uit de tijd van PHP3, waarin register_globals nog aan stond... Die site is medeschuldig aan het feit dat hier nog zoveel register_globals-gerelateerde vragen voorbij komen.

[Japidoff]

kijk eens naar http://nl2.php.net/manual/en/function.move-uploaded-file.php

volgens mij kan je een bestandsnaam in _FILES[] niet direct aanspreken, je moet m eerst verplaatsen..

(als ik t me goed herinner)

PHP:

<?php
if (move_uploaded_file($_FILES['filename']['tmp_name'], $new_filename)) {
     gelukt
}
?>

offtopic:
zijn we hier om gezellig problemen op te lossen, of om elkaar lekker af te zeiken???
[edit]
ik las t nog s door, en t viel ook wel mee.. no offence
[/edit]

[ Voor 42% gewijzigd door Japidoff op 12-09-2006 17:19 ]

[Dark Wanderer]

Zozo, wat een activiteit opeens op mijn topic, een ware discussie

Maar om even duidelijk te maken wat ik wil. Ik maak een pagina voor school waar we documentjes op kunnen slaan, tot en met een grootte van 10 mb. Ik wil deze graag in de db pleuren omdat ik dat zeg maar netjes vind staan (en ik had het nog nooit eerder gedaan, leek me leuk om er eens mee te experimenteren).

De bestanden zijn echt van diverse soorten, zoals .doc, .ppt. .jpg enzovoorts. Het is echt een download pagina.

Ik heb het ondertussen op de manier opgelost zonder mysql blob, omdat die reactie van het forum phpfreaks.nl afkwam, en tegen die tijd stonden al deze reacties nog niet op GOT.

Het moge dus duidelijk zijn dat dit niet een pagina wordt met duizenden bezoekers, want kan ik me voorstellen dat je dan de database alleen maar extra belast terwijl je het dan net zo goed in een map kan pleuren. Ik deed het vooral om zoals ik al zei te experimenteren, en omdat ik dan geen last heb van dubbele bestandsnamen, en ook omdat de bestandsnamen dan niet uitmaken (speciale tekens en spaties en zo).

[Dark Wanderer]

En nog even een kleine offtopic vraag, wat zouden, volgens de pro's onder ons, de redenen zijn voor DB opslag en de redenen voor FS opslag?

[CyBeR]

Als je meerdere servers hebt scheelt 't je al een hoop gezeik met filesystem synchronisatie. Gewoon je files uit je db trekken. Doen wij ook

Wat we dan wel hebben voor verhoogde performance is een static content cache server die ervoor hangt en als frontend dient voor de files. Je vraagt dan op http://static.site.com/f/abcd/images/foo.jpg, en dan kijkt die server gewoon op z'n fs (apache die gewoon een file served) of 'ie 'm heeft. Zo niet komt de 404 handler in werking die de file ophaalt bij de echte webserver, opslaat op 't filesystem en doorstuurt naar de client alsof er nooit een 404 geweest is. De volgende client krijgt die file vervolgens vanaf 't fs geserved. (Of om precies te zijn uit geheugen, want voor apache zit dan ook nog weer een caching webserver die alles in geheugen bijhoudt). Het geheel is retesnel (En niet verplicht, je kunt de files ook nog gewoon bij de webserver opvragen).

[ Voor 4% gewijzigd door CyBeR op 12-09-2006 19:08 ]

[Dark Wanderer]

CyBeR schreef op dinsdag 12 september 2006 @ 19:07:
Als je meerdere servers hebt scheelt 't je al een hoop gezeik met filesystem synchronisatie. Gewoon je files uit je db trekken. Doen wij ook

Wat we dan wel hebben voor verhoogde performance is een static content cache server die ervoor hangt en als frontend dient voor de files. Je vraagt dan op http://static.site.com/f/abcd/images/foo.jpg, en dan kijkt die server gewoon op z'n fs (apache die gewoon een file served) of 'ie 'm heeft. Zo niet komt de 404 handler in werking die de file ophaalt bij de echte webserver, opslaat op 't filesystem en doorstuurt naar de client alsof er nooit een 404 geweest is. De volgende client krijgt die file vervolgens vanaf 't fs geserved. (Of om precies te zijn uit geheugen, want voor apache zit dan ook nog weer een caching webserver die alles in geheugen bijhoudt). Het geheel is retesnel (En niet verplicht, je kunt de files ook nog gewoon bij de webserver opvragen).

Hahah klinkt ingewikkeld, laat ik het maar even lekker direct uit de db of direct uit de FS halen

[Gomez12]

Dark Wanderer schreef op dinsdag 12 september 2006 @ 18:58:
En nog even een kleine offtopic vraag, wat zouden, volgens de pro's onder ons, de redenen zijn voor DB opslag en de redenen voor FS opslag?

Geen pro hier, gewone hobbyist.

Maar volgens mij zijn de belangrijkste punten :
Pro DB
Makkelijke backup mogelijkheden ( je backupt maar 1 db ipv 1 db + x files )
Alles loopt via 1 dbaseserver ( beveiliging / backup / synchronisaties etc etc ) die toch dit allemaal al moet hebben voor je db. Dus 1 standaard methode.
Virtuele mappen aanmaken is zo gebeurd, 1 bestand opslaan gebeurt echt maar 1x al moet hij in 100.000 mappen getoond worden, 1 persoon verandert het bestand dan hoef je er pas 2 te hebben. Niet eerder ( dus geen afhankelijkheid van of het FS wel hard/soft links kent maar wederom standaard methode )

Con DB
Het kost performance ( is zoals cyber al schrijft goed op te vangen door een inteligent fs cache, maar dan sla je het wel weer dubbel op, dus meer aanschafkosten )
Het kost geheugen ( zie fs cache )
Het kost snelheid ( zie fs cache )
indien je geen dbase backup kan maken ben je in 1x ook nog eens je bestanden kwijt.

Daarom hangt het voornamelijk van de grote van het project af, kunnen de kosten voor een goede cache gemaakt worden dan zou ik altijd kiezen voor in de DB vanwege beheersmogelijkheden.
Moet het zo goedkoop mogelijk dan zou ik kiezen voor een tussenoplossing ( je hele FAT in de db gooien en de echte data op fs gooien ) je kan nu nog steeds virtuele mappen aanmaken etc, alleen loopt er ook nog steeds 1 query naar je dbase voor de bestandsnaam.

Dan sla je gewoon een bestand op als zijnde bestand1.dat en in je dbase maak je dan een koppeltabel met daarin fsname ( bestand1.dat ) en filename ( lekkeregeileporno.jpg ). Als dan het bestand lekkeregeileporno.jpg opgeroepen wordt dan vraag je aan de dbase hoe het bestand heet en waar het staat en apache serveert dan gewoon bestand1.dat alszijnde lekkerkerkergeileporno.jpg, gebruiker merkt hier niets van.

Maar volgens mij is het ook pas echt een issue bij grotere implementaties, als er echt een beheerbeleid moet zijn en het dus handiger is om gewoon 1 ding maar te hoeven backuppen ongeacht wat er in staat dan kan alleen DB handig zijn vanwege beheergemak. Maar in de praktijk zit er dan toch nog bijna altijd wel een FS cache tussen zodat feitelijk het bestand wat opgehaald wordt in 95% van de gevallen van het FS vandaan komt.
Maar bij kleinere implementaties is er gewoon het geld niet beschikbaar voor een nette db oplossing dus wordt er niet voor gekozen.