MySQL - PHP -> picture database - Softwareontwikkeling

dinsdag 10 oktober 2000 10:21

Acties:

Verwijderd

Topicstarter

Ik ben nieuw in deze wereld. Maar wil het een en ander opzetten.

Een "Picture Of The Day" systeem. Zoals je kan zien op http://www.benel.com/powershot/morepotw.php3

Hoe ga ik het best te werk? Op mijn server heb ik zowel MySQL als PHP.

Waar ik mee zit, zijn de volgende vragen.

* Mijn foto's steek ik die in de database als binaries. Hoe doe ik dat? OF zet ik alle foto's in één directory, en steek hun filenaam in de database.

* Ik wil gemakkelijk kunnen opvragen op datum. Gebruik ik dan best het dagnummer? Of gewoon datum in database stoppen?

* Upload van de foto's. Hoe zou ik dat het best doen? We zouden met een aantal mensen dit moeten kunnen doen. Foto en hun omschrijving.

Alle tips zijn welkom! Ook als het niet tussen mijn vragen staat.

thanks, p.

dinsdag 10 oktober 2000 10:25

Acties:

Verwijderd

* Mijn foto's steek ik die in de database als binaries. Hoe doe ik dat? OF zet ik alle foto's in één directory, en steek hun filenaam in de database.

Kan allebei.

* Ik wil gemakkelijk kunnen opvragen op datum. Gebruik ik dan best het dagnummer? Of gewoon datum in database stoppen?

Als je op datum wilt zoeken stop je een datum in de db.

* Upload van de foto's. Hoe zou ik dat het best doen? We zouden met een aantal mensen dit moeten kunnen doen. Foto en hun omschrijving.

Maak een upload script en een pagina voor het uploaden. Zoek naar zoiets voor PHP.

HTH

dinsdag 10 oktober 2000 10:29

Acties:

Verwijderd

Een kleine tip:
Zet niet de foto's zelf, maar alleen de links naar de foto's in de database. Dit resulteerd in een meer stabiele database en betere beheersbaarheid.

dinsdag 10 oktober 2000 10:35

Acties:

Verwijderd

Zet niet de foto's zelf, maar alleen de links naar de foto's in de database. Dit resulteerd in een meer stabiele database en betere beheersbaarheid.

Waarom?

Foto's in de database betekent meer werk voor de db, maar is beter beheersbaar.

Hoe maak het uit voor je databse of er foto's inzitten voor je stabiliteit? Niet.

dinsdag 10 oktober 2000 10:41

Acties:

Verwijderd

Arien, ik ben het met je eens dat plaatjes in de DB beter beheersbaar zijn, maar de stabiliteit van de DB zal wel veranderen. Aangezien er meer data in de DB zit zal er intensiever gebruik worden gemaakt van de DB en daarbij zal de kans op deadlocks en andere problemen toenemen.

dinsdag 10 oktober 2000 10:46

Acties:

Verwijderd

Topicstarter

<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Op 10 oktober 2000 10:29 schreef Anchorman het volgende:
Een kleine tip:
Zet niet de foto's zelf, maar alleen de links naar de foto's in de database. Dit resulteerd in een meer stabiele database en betere beheersbaarheid.[/quote]Hoe bedoel je dan? Je maakt een databaseveld met daarin bijvoorbeeld:

http://www.myserver.com/images/10-10-00.jpg

dinsdag 10 oktober 2000 10:48

Acties:

Verwijderd

De stabiliteit van de DB zal wel veranderen. Aangezien er meer data in de DB zit zal er intensiever gebruik worden gemaakt van de DB en daarbij zal de kans op deadlocks en andere problemen toenemen.

Deadlocks? Als ik meer gegevens uit een database lees? Met 99.99% lezen deadlocks? Dan wordt het heel hoog tijd voor een ander DBMS.

Stabiliteit moet geen probleem zijn.

dinsdag 10 oktober 2000 10:54

Acties:

Tha_LeX

Ik heb zelf ook de plaatjes als binaries in de database gezet, maar de snelheid wordt d'r inderdaad wel minder op,

maar een voordeel vind ik dat het makkelijker beheerbaar is en ik kan de plaatjes gewoon via een script verwijderen

<?php

if($id) {

@MYSQL_CONNECT("localhost","****","****");

@mysql_select_db("nr14db");

$query = "select bin_data,filetype from binary_data where id=$id";
$result = @MYSQL_QUERY($query);

$data = @MYSQL_RESULT($result,0,"bin_data");
$type = @MYSQL_RESULT($result,0,"filetype");

Header( "Content-type: $type");
echo $data;

};
?>

Dit is de file om het plaatje uit de database op te roepen

<HTML>
<HEAD><TITLE>Store binary data into SQL Database</TITLE></HEAD>

<body background="bg1.jpg">

<?php

if ($submit) {

MYSQL_CONNECT("localhost","****","****");
mysql_select_db("nr14db");

$data = addslashes(fread(fopen($form_data, "r"), filesize($form_data)));

$result=MYSQL_QUERY("INSERT INTO binary_data (description,bin_data,filename,
filesize,filetype) ".
"VALUES ('$form_description','$data','$form_data_name','$form_data_size'
,'$form_data_type')");

$id= mysql_insert_id();
print "<p>This file has the following Database ID: <b>$id</b>";

MYSQL_CLOSE();

} else {

?>

<form method="post" action="<?php echo $PHP_SELF; ?>" enctype="multipart/for
m-data">
File Description:<br>
<input type="text" name="form_description" size="40">
<INPUT TYPE="hidden" name="MAX_FILE_SIZE" value="1000000">
<br>File to upload/store in database:<br>
<input type="file" name="form_data" size="40">
<p><input type="submit" name="submit" value="submit">
</form>

<?php

}

?>

</BODY>
</HTML>

Dit is de code om het plaatje uit de database te halen

CREATE TABLE binary_data (
id int(4) DEFAULT '0' NOT NULL auto_increment,
description varchar(50),
bin_data longblob,
filename varchar(50),
filesize varchar(50),
filetype varchar(50),
UNIQUE id (id)
);

Het tabel voor de plaatjes

En nu kan je het plaatje in een pagina zetten door : er neer te zetten

Roses are red, violets are blue, God made me beautiful, but what the FUCK happened to you?

dinsdag 10 oktober 2000 16:14

Acties:

dusty

Celebrate Life!

als je de plaatjes in de DB stopt blijft de stabiliteit van de DB hetzelfde. echter de snelheid waarmee de db reageert valt drastisch terug.

Vooral als je veel plaatjes in de db stopt.

dus stop alleen de link naar je plaatjes in de database. (met de eventuele andere dingen die je wilt hebben , date , titel, beschrijving etc etc...)

Back In Black!
"Je moet haar alleen aan de ketting leggen" - MueR

dinsdag 10 oktober 2000 16:23

Acties:

Verwijderd

als je de plaatjes in de DB stopt blijft de stabiliteit van de DB hetzelfde. echter de snelheid waarmee de db reageert valt drastisch terug. Vooral als je veel plaatjes in de db stopt.

Dus je databaseserver kan niet hetzelfde dat je webserver kan? Die moet namelijk ook al die bestanden opzoeken en sturen...

woensdag 11 oktober 2000 13:17

Acties:

CubicQ

Ik heb hetzelfde ooit gevraagd in de newsgroup nl.internet.www.server-side:
http://www.deja.com/=dnc/[ST_rn=ps]/viewthread.xp?search=thread&recnum=%3c2vomos0mkuo6oeb6l57aolc2qjr0lo358e@4ax.com%3e%231/1&AN=654628189&svcclass=dnserver&frpage=viewthread.xp

Zinnen die erg leerzaam zijn in dit geval: "Een plaatje naar de database schrijven is
complexer dan een plaatje naar een bestand schrijven." en "... dus
heb je eigenlijk een extra laag tussen filesystem en plaatjes die de zaak
eigenlijk alleen maar vertraagt."

woensdag 11 oktober 2000 13:24

Acties:

Verwijderd

"Een plaatje naar de database schrijven is complexer dan een plaatje naar een bestand schrijven." en "... dus heb je eigenlijk een extra laag tussen filesystem en plaatjes die de zaak eigenlijk alleen maar vertraagt."

Heel leuk, maar 99.99% is lezen.

woensdag 11 oktober 2000 13:29

Acties:

tomato

<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Op 11 oktober 2000 13:24 schreef Arien het volgende:
"Een plaatje naar de database schrijven is complexer dan een plaatje naar een bestand schrijven." en "... dus heb je eigenlijk een extra laag tussen filesystem en plaatjes die de zaak eigenlijk alleen maar vertraagt."

Heel leuk, maar 99.99% is lezen.[/quote]Misschien gaat soortgelijks ook op voor lezen?!? Lijkt me niet geheel onlogisch.

woensdag 11 oktober 2000 13:30

Acties:

Onno

<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Een plaatje naar de database schrijven is complexer dan een plaatje naar een bestand schrijven. ... dus heb je eigenlijk een extra laag tussen filesystem en plaatjes die de zaak eigenlijk alleen maar vertraagt.[/quote]Dan gebruik je toch het datatype BFILE? Oh nee, kent MySQL niet...

woensdag 11 oktober 2000 13:36

Acties:

Verwijderd

Misschien gaat soortgelijks ook op voor lezen?!? Lijkt me niet geheel onlogisch.

En hoe krijg een file uit een filesystem? Je kunt de db ook zien als een filesystem, maar dan geoptimaliseerd want je geeft al een structuur aan. Ik wil dat nog wel eens horen dat het een performance hit geeft.

woensdag 11 oktober 2000 13:51

Acties:

tomato

Ik weet het, een zwak argument, temeer zonder harde url, maar keer op keer bewijzen performance tests dat van veel binaire data in je db je db trager wordt. Veel trager zelfs.

En misschien is het wel belangrijk waar we het nu precies over hebben:

1)Performance van de webserver
2)Performance van de database server.
(3)Performance van het totaal (web+db server) bij opvragen van een plaatje)

Dat scheelt denk ik nogal. Punt 3 is niet echt relevant, hoewel sommigen beweren dat dit ook beter gaat wanneer het plaatje niet in de database staat.
Punt 1 zal denk ik niet echt achteruit gaan bij plaatsen van plaatjes op de webserver (niet in de database) en punt 2 zal hier al helemaal niets van merken.
Bij het opslaan van je plaatjes in de db zal je een enorme performance loss zien bij punt 2 (db server), terwijl je webserver hier niet veel van zal merken.

Wat is er nu belangrijk? Ik denk dat het belangrijk is om je database zo min mogelijk te belasten, dus lijkt het me duidelijk.

woensdag 11 oktober 2000 13:51

Acties:

CubicQ

<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Op 11 oktober 2000 13:30 schreef Onno het volgende:
Dan gebruik je toch het datatype BFILE? Oh nee, kent MySQL niet... ;)[/quote]Ik ken BFILE niet, maar ik stel me zo voor dat dat een sortof BLOB is dat in een aparte file wordt opgeslagen? Dan heb je dat probleem nog steeds:
i.p.v. filesysteem -> http-server heb je filesysteem -> database -> http-server.<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Op 11 oktober 2000 13:36 schreef Arien het volgende:
Misschien gaat soortgelijks ook op voor lezen?!? Lijkt me niet geheel onlogisch.

En hoe krijg een file uit een filesystem? Je kunt de db ook zien als een filesystem, maar dan geoptimaliseerd want je geeft al een structuur aan. Ik wil dat nog wel eens horen dat het een performance hit geeft.[/quote](de twee zinnen zijn trouwens door verschillende mensen geschreven en 'horen' niet achter elkaar, voor de duidelijkheid

edit:
Hiermee bedoel ik dus de twee gequote zinnen uit mijn eerste stukje mee, ik heb het idee dat ik het allemaal niet echt duidelijker maak zo

)

Dan ga je uit van een dbms die direct op de harddisk schrijft (zoals Oracle toch?). MySQL (en volgens mij Postgress ook wel) schrijven via het filesysteem, dus is het gewoon een extra laag. Postgress slaat een BLOB trouwens als een aparte file op, dus dan kan het per definitie niet sneller zijn.

Wat verder een nadeel is: een plaatje uit een database wordt niet gecached door proxies etc. onderweg.

woensdag 11 oktober 2000 13:59

Acties:

Onno

<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>i.p.v. filesysteem -> http-server heb je filesysteem -> database -> http-server.[/quote]Jawel, maar php -> database, en vervolgens php -> bestandssysteem is echt niet sneller dan php -> database -> bestandssysteem hoor... en daarnaast, zoals je zelf al zegt...<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>een dbms die direct op de harddisk schrijft (zoals Oracle[/quote]:)<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Wat verder een nadeel is: een plaatje uit een database wordt niet gecached door proxies etc. onderweg.[/quote]Uhm, dat kun je met HTTP header fields gewoon instellen hoor. (of er gecachet moet worden of niet)

woensdag 11 oktober 2000 14:33

Acties:

Verwijderd

MySQL (en volgens mij Postgress ook wel) schrijven via het filesysteem, dus is het gewoon een extra laag. Postgress slaat een BLOB trouwens als een aparte file op, dus dan kan het per definitie niet sneller zijn.

Maar of het nou veel langzamer is? Zoals je al aangeeft gebruikt Postgress een file pre BLOB, dus file opentrekken met Apache of met Postgress...

Wat verder een nadeel is: een plaatje uit een database wordt niet gecached door proxies etc. onderweg.

Waarom niet? Als je de goede headers meestuurt wel.

woensdag 11 oktober 2000 14:34

Acties:

Verwijderd

Keer op keer bewijzen performance tests dat van veel binaire data in je db je db trager wordt. Veel trager zelfs.
Wat maakt het soort data nou uit. Dat intereseert die db niets.

[Verschil in performance van het totaal] is niet echt relevant, hoewel sommigen beweren dat dit ook beter gaat wanneer het plaatje niet in de database staat.
Hangt van de netwerk configuratie af en kan je webserver performance erg gunstig beinvoelden.

[Performance van je webserver] zal denk ik niet echt achteruit gaan bij plaatsen van plaatjes op de webserver (niet in de database)....
Je webserver hoeft de niet op te zoeken in het filesysteem, headers ervoorzetten, etc?

...en [performance van de database server] zal hier al helemaal niets van merken.
Als de plaatjes op de webserver staan? Dan krijgt je dbserver het rustiger natuurlijk.

Bij het opslaan van je plaatjes in de db zal je een enorme performance loss zien bij db server), terwijl je webserver hier niet veel van zal merken.
Argumenten.

Wat is er nu belangrijk? Ik denk dat het belangrijk is om je database zo min mogelijk te belasten, dus lijkt het me duidelijk.
Belangrijk is optimale performance en onderhoudbaarheid en ik ben het dus niet met je eens.

vrijdag 13 oktober 2000 14:43

Acties:

Verwijderd

Waar gaat het over

Picture of the day -> veel plaatjes (en veel bezoeken). Mensen die regelmatig bezoeken willen graag gebruik maken van cache. En dat is meteen ook beter voor de performance.

Ik zou gaan voor de plaatjes los.

Beheersbaarheid is beetje wazig hier hoor, want je kan gewoon een scriptje maken dat uit de database de filenaam leest, de file verwijdert en dan de dbentry weghaalt.

Als het werkt, laat ff zien dan hier

vrijdag 13 oktober 2000 15:05

Acties:

Verwijderd

Picture of the day -> veel plaatjes (en veel bezoeken). Mensen die regelmatig bezoeken willen graag gebruik maken van cache. En dat is meteen ook beter voor de performance.

Daar houden pics in de db je echt niet bij tegen. Gewoon de goede headers mee sturen.

Ik zou gaan voor de plaatjes los.

Dat kan.

Beheersbaarheid is beetje wazig hier hoor, want je kan gewoon een scriptje maken dat uit de database de filenaam leest, de file verwijdert en dan de dbentry weghaalt.

Dus je haalt wel de filenamen uit de database en een paar pics niet? Omdat dat geen tekstformaat is ofzo? Ik zie de logica niet.

vrijdag 13 oktober 2000 15:25

Acties:

raptorix

Ik zou gaan voor best of both worlds, het is algemeen bekent dat het halen van images uit de database gewoon minder snel gaat, dus wat ik zou zeggen zet wel je plaatjes in de database maar maak gewoon een script dat 1 keer per dag of andere periode, dat de images weggeschreven worden naar de betreffende image dirs, zo heb je goede snelheid en heb je toch je images in de database

vrijdag 13 oktober 2000 15:39

Acties:

Verwijderd

Het is algemeen bekent dat het halen van images uit de database gewoon minder snel gaat,...

Link? Benchmark? Verder: Waarom zou iemand nog databases gebruiken als de dingen die erin staan zo langzaam eruit te halen zijn? Je kan beter alles in losse files zetten.

... dus wat ik zou zeggen zet wel je plaatjes in de database maar maak gewoon een script dat 1 keer per dag of andere periode, dat de images weggeschreven worden naar de betreffende image dirs, zo heb je goede snelheid en heb je toch je images in de database

Dus je gaat wel een verbinding met de database maken, het adres enzo van het plaatje opzoeken (dus traag is, want komt uit de databse, zie boven) en vervolgens haal je het plaatje uit je file-systeem? Wat is de logica daarvan?

donderdag 5 juli 2001 13:22

Acties:

Verwijderd

Sorry voor het opnieuw omhoogschoppen van dit topic maar...
Dat scriptje van Tha_Lex werkt niet helemaal goed bij mij, als ik een plaatje upload, en het weeer probeer op te halen... dan vervormt de onderkant...
Wat kan ik hier tegen doen?
ik heb ookal het script van phpbuilder gebuikt maar dat werkt zelfs helemaal niet

ik ben nu al een paar uut bezig... kan iemand me alsjeblief ff helpen

zondag 30 december 2001 14:15

Acties:

Verwijderd

zou zo'n dbtje ook functioneel zijn met ruim 40.000 images in heeeel veel catagorieen?

(ruim 2gb aan images)

zondag 30 december 2001 15:32

Acties:

Verwijderd

Op woensdag 11 oktober 2000 14:33 schreef Arien het volgende:
MySQL (en volgens mij Postgress ook wel) schrijven via het filesysteem, dus is het gewoon een extra laag. Postgress slaat een BLOB trouwens als een aparte file op, dus dan kan het per definitie niet sneller zijn.

Tuurlijk wel, als de server niet localhost draait moet je alles door je netwerk pompen.. En als je het gewoon met een link doet is er minder communicatie tussen dbserver en php en dit versnelt het ook..

zondag 30 december 2001 19:07

Acties:

Rense Klinkenberg

<xml />

Voor het geval MySQL als database-server wordt gebruikt, is het misschien handig als http://www.mysql.com/doc/T/i/Tips.html wordt doorgelezen, waarin de makers van MySQL het volgende zeggen:

When using a normal Web server setup, images should be stored as files. That is, store only a file reference in the database. The main reason for this is that a normal Web server is much better at caching files than database contents. So it it's much easier to get a fast system if you are using files.

Voordat iedereen hier nu gaat lopen schreeuwen dat het bij een goede database misschien anders zou moeten zijn: ik heb het hier dus alleen over MySQL!

* Rense Klinkenberg kan zich trouwens herinneren dat over dit onderwerp al eens een topic is geweest, die met de search vast te vinden zou zijn geweest

dinsdag 19 november 2002 23:08

Acties:

Undertaker2

Even een kickje na bijna 1 jaar.

De constructie van Da-Lex is leuk, zei het niet dat door het gebruik van de PHP- en de HTML-code op DEZELFDE pagina ervoor zorgt dat, wanneer de submit button is ingedrukt, de standaardvariabelen zoals userfile_name en userfile_size NIET meer beschikbaar zijn.

Wanneer je met de submit button een ander PHP document aanroept (bijv. do_upload.php) en je zet daar de php-code in, dan heb je daar opeens wel weer de beschikking over userfile_name etc.

AMD PoloMarco 23500 gigakilometer - 96" Quadcrystal scherm - Detonator 28010.25 afgerond op 2 decimalen - PlakBand @ 768 TB - 512 GB ZIGB - UltraFlex 100 GPU @ 5.5 ghz / 10 ghz - Isootjes @ 1 GB/sec

dinsdag 19 november 2002 23:24

Acties:

ACM

Software Architect

Werkt hier

Dat is leuk, maar daar had je het topic niet voor hoeven kicken na een jaar (en het was al es eerder na een jaar gekicked!)

En volgens mij praat je onzin, volgens mij kan je prima de standaard waarden voor userfile_name/size beschikbaar maken binnen dezelfde php/html.
Behalve dat ik niet helemaal snap waar je het over hebt.

Magoed, imho geen gerechtigde kick en dus een slotje.

Pagina: 1

Dit topic is gesloten.