Re: [PHP] Re: pictures stored in PostgreSQL DB
At 5:14 PM -0500 3/5/07, markw@mohawksoft.com wrote: The "science" is computer science and that is mostly mathematics based. The "art" is the creativity of coming up with novel solutions. The thing that separates "engineering" from "art" is the fact that after the abstract creativity takes place, it is verified against the science. All hogwash -- and not even well said. tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: pictures stored in PostgreSQL DB
On Mon, 2007-03-05 at 17:08 -0500, markw@mohawksoft.com wrote: > > On Mon, 2007-03-05 at 14:48 -0500, markw@mohawksoft.com wrote: > >> > On Mon, 2007-03-05 at 10:16 -0500, Mark wrote: > > >> "I gained nothing at all from supreme enlightenment - and for that very > >> reason, it is called supreme enlightenment" > >> > >> Buddha. > > > > "Supreme enlightenment is only possible after death, > > That depends on your philosophical underpinnings I suppose. > "Enlightenment," is an interesting topic, one I'm pretty sure goes WAY off > topic on this list. Nah, on this list almost anything goes. Even futile opinion pieces purporting that filesystems are necessarily better than databases for storing images. But at any rate, my thoughts on "Supreme Enlightenment" would be "All knowing" since anything otherwise wouldn't be quite "enlightended". As such, that would require more bits to encode as knowledge than materials exist in the universe to encode the knowledge... and even then those bits themselves would need to be accounted for. > > and that presumes there's an afterlife > > Assumptions without proof do not a logical argument make. I keep telling you that. > > that does not have the restrictions of our currently reality. > > Most people don't even know what reality is. I never claimed to know what it was, I'm only making some guesses with what little I presume. > > Once you're dead, I highly doubt anyone's is going to > > care about your filesystem argument (or my counter argument for that > > matter). Besides, everyone knows God stores reality in a database. All > > your images belong to him." > > As an atheist, I store god in the bit bucket, where [s]he/it belongs. As an atheist why do you bother stumbling upon the gender issue? Why even assign a gender? > >> I have yet to see one implementation or strategy where putting bitmap > >> data > >> in a database can not be accomplished more efficiently using a different > >> approach. Bitmap data does not belong in a SQL database because it is > >> not > >> something that is of any use to the algebraic relational syntax of SQL, > >> thus it is more efficient to store a reference to the data rather than > >> the > >> data itself. > > > > Image data can benefit from proximity to meta data that describes it > > that is in a relational database. > > This is a false assumption. What possible benefit is gained? That's not an assumption, it's a fact. If I've already accessed a location on the hard drive where the meta data exists, and the binary data is beside it, then I can retrieve the binary data quite likely without another seek. As such, the time to retrieve is decreased and I was going to retrieve the meta data anyways. Using the filesystem, where the data is not in any kind of proximity would suggest a seek (not withstanding caching). > > You incorrect presumption is that one > > would want to make some kind of algebraic query against the binary data > > itself, when in fact quite often we merely want to retrieve the data due > > it's relevance to some other field upon which a query has been made. > > Apart from a misunderstanding of what I wrote in your first sentence, the > rest reads correctly. > > The functionality can be as easily implemented and more efficiently using > references instead of the data. Sounds like you want to make a database out of a filesystem. Once again, as I've mentioned numerous times, there is little your file system implementation can do to make the following a more succinct piece of code: > >> Putting database data in the database needlessly increases load on the > >> database. If you are using MySQL, the tables in which the bitmap is > >> stored > >> are read-locked during the read of the data. If the data is large, it > >> can > >> use up buffering resources otherwise used to increase query performance. > > > > Putting image data on the filesystem when it has related fields in the > > database needlessly increases the load on the complexity of the > > application. > > Please explain how. You have to put a reference in the HTML stream for a > later HTTP request from the browser anyway. Where is the complexity coming > from? Development. > If you upload an image to the web server, it is stored in a temp directory > and must be moved. I find it difficult to quantify any real added > complexity between a file system move and a database insert. That's insertion. What about retrieval, deletion, and backup? > >> Bitmap image data can not be incorporated into the HTML stream with the > >> rest of the data retrieved. A reference must be created in the HTML > >> document so that the client web browser can issue a new HTTP request for > >> the image. It is more efficient to put a reference in the database and > >> have the browser query directly for the image against a file based > >> system. > > > > Filesystem data cannot be directly incorporated into the browser request > > when a custom authentication system is in pl
Re: [PHP] Re: pictures stored in PostgreSQL DB
> On Mon, 2007-03-05 at 14:48 -0500, markw@mohawksoft.com wrote: >> > On Mon, 2007-03-05 at 10:16 -0500, Mark wrote: >> >> Alain Roger wrote: >> >> >> >> > Hi, >> >> > >> >> > It's amazing that my previous post has raised so much consideration >> >> about >> >> > the fact to store or not pictures into DB. >> >> >> >> And yet you ask again!? Did you not learn? No good can come from this >> >> question. >> > >> > He didn't care about the debate. He is already using a database and >> > wants to display the images. I'm sure he learned plenty, but not what >> he >> > wanted to learn. >> >> "I gained nothing at all from supreme enlightenment - and for that very >> reason, it is called supreme enlightenment" >> >> Buddha. > > "Supreme enlightenment is only possible after death, That depends on your philosophical underpinnings I suppose. "Enlightenment," is an interesting topic, one I'm pretty sure goes WAY off topic on this list. > and that presumes there's an afterlife Assumptions without proof do not a logical argument make. > that does not have the restrictions of our currently reality. Most people don't even know what reality is. > Once you're dead, I highly doubt anyone's is going to > care about your filesystem argument (or my counter argument for that > matter). Besides, everyone knows God stores reality in a database. All > your images belong to him." As an atheist, I store god in the bit bucket, where [s]he/it belongs. > >> > I'd say the most important outcome of the side-track >> > debate was to clarify that it depends on what you are working with, >> what >> > you are doing, what your tolerance is for various types of solutions, >> > and where those tolerances lie. An important thing we also learned, is >> > that while filesystem storage is often the better solution, it is not >> > always the best solution, especially when factoring in such things as >> > convenience and simplicity. >> >> I don't think we came to any such conclusion. I still assert that while >> there may be multiple "right" ways to accomplish a task, there are often >> clearly "wrong" ways. Putting bitmap data inside the database is a >> mistake. > > By "we" you mean "you" and perhaps some other edge believers. > >> Before y'all got hyper-literal trying to argue the finer details of the >> definition of "mistake," my assertion is this: >> >> I have yet to see one implementation or strategy where putting bitmap >> data >> in a database can not be accomplished more efficiently using a different >> approach. Bitmap data does not belong in a SQL database because it is >> not >> something that is of any use to the algebraic relational syntax of SQL, >> thus it is more efficient to store a reference to the data rather than >> the >> data itself. > > Image data can benefit from proximity to meta data that describes it > that is in a relational database. This is a false assumption. What possible benefit is gained? > You incorrect presumption is that one > would want to make some kind of algebraic query against the binary data > itself, when in fact quite often we merely want to retrieve the data due > it's relevance to some other field upon which a query has been made. Apart from a misunderstanding of what I wrote in your first sentence, the rest reads correctly. The functionality can be as easily implemented and more efficiently using references instead of the data. > >> Putting database data in the database needlessly increases load on the >> database. If you are using MySQL, the tables in which the bitmap is >> stored >> are read-locked during the read of the data. If the data is large, it >> can >> use up buffering resources otherwise used to increase query performance. > > Putting image data on the filesystem when it has related fields in the > database needlessly increases the load on the complexity of the > application. Please explain how. You have to put a reference in the HTML stream for a later HTTP request from the browser anyway. Where is the complexity coming from? If you upload an image to the web server, it is stored in a temp directory and must be moved. I find it difficult to quantify any real added complexity between a file system move and a database insert. > >> Bitmap image data can not be incorporated into the HTML stream with the >> rest of the data retrieved. A reference must be created in the HTML >> document so that the client web browser can issue a new HTTP request for >> the image. It is more efficient to put a reference in the database and >> have the browser query directly for the image against a file based >> system. > > Filesystem data cannot be directly incorporated into the browser request > when a custom authentication system is in place that requires wrapping > the file request in a PHP script. Your argument keep going back to the > same refuted point. YOU CANNOT ALLOW DIRECT REQUESTING OF SENSITIVE > DATA. No need for caps. There are many better ways of implementing authorization to acce
Re: [PHP] Re: pictures stored in PostgreSQL DB
Robert Cummings escribió: On Mon, 2007-03-05 at 14:48 -0500, markw@mohawksoft.com wrote: Yea, and 1+1 = what ever the engineer or the business requirements want it to be, right? Once again it depends. What base are we working in? Are we working in some kind of odd algebraic space? 1+1 only equals 2 in specific situations. Well, it's really the metric of the space you're in. That is, how you are going to measure things. :-) This is engineering, not art class. There are ways to evaluate solutions as being better than others. This is computer science, not engineering. There are considerations for one approach over another not necessarily confined to your idea of "efficiency". The problem encompasses time, space, economics, and any number of other dimensions. Most people put programming nearer to literature, art and mathematics then to physics and mechanic. So I would say that we are closer to an art class then to a class of engineering. :-D -- select 'mmarques' || '@' || 'unl.edu.ar' AS email; - Martín Marqués | Programador, DBA Centro de Telemática| Administrador Universidad Nacional del Litoral - -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: pictures stored in PostgreSQL DB
> Robert Cummings escribió: >>> This is engineering, not art class. There are ways to evaluate >>> solutions >>> as being better than others. >> >> This is computer science, not engineering. There are considerations for >> one approach over another not necessarily confined to your idea of >> "efficiency". The problem encompasses time, space, economics, and any >> number of other dimensions. > > Most people put programming nearer to literature, art and mathematics > then to physics and mechanic. So I would say that we are closer to an > art class then to a class of engineering. :-D I'm pretty old-school when it comes to computer engineering. Like any "engineering" there is both "science" and "art" involved. The "science" is computer science and that is mostly mathematics based. The "art" is the creativity of coming up with novel solutions. The thing that separates "engineering" from "art" is the fact that after the abstract creativity takes place, it is verified against the science. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: pictures stored in PostgreSQL DB
On Mon, 2007-03-05 at 14:48 -0500, markw@mohawksoft.com wrote: > > On Mon, 2007-03-05 at 10:16 -0500, Mark wrote: > >> Alain Roger wrote: > >> > >> > Hi, > >> > > >> > It's amazing that my previous post has raised so much consideration > >> about > >> > the fact to store or not pictures into DB. > >> > >> And yet you ask again!? Did you not learn? No good can come from this > >> question. > > > > He didn't care about the debate. He is already using a database and > > wants to display the images. I'm sure he learned plenty, but not what he > > wanted to learn. > > "I gained nothing at all from supreme enlightenment - and for that very > reason, it is called supreme enlightenment" > > Buddha. "Supreme enlightenment is only possible after death, and that presumes there's an afterlife that does not have the restrictions of our currently reality. Once you're dead, I highly doubt anyone's is going to care about your filesystem argument (or my counter argument for that matter). Besides, everyone knows God stores reality in a database. All your images belong to him." Me > > I'd say the most important outcome of the side-track > > debate was to clarify that it depends on what you are working with, what > > you are doing, what your tolerance is for various types of solutions, > > and where those tolerances lie. An important thing we also learned, is > > that while filesystem storage is often the better solution, it is not > > always the best solution, especially when factoring in such things as > > convenience and simplicity. > > I don't think we came to any such conclusion. I still assert that while > there may be multiple "right" ways to accomplish a task, there are often > clearly "wrong" ways. Putting bitmap data inside the database is a > mistake. By "we" you mean "you" and perhaps some other edge believers. > Before y'all got hyper-literal trying to argue the finer details of the > definition of "mistake," my assertion is this: > > I have yet to see one implementation or strategy where putting bitmap data > in a database can not be accomplished more efficiently using a different > approach. Bitmap data does not belong in a SQL database because it is not > something that is of any use to the algebraic relational syntax of SQL, > thus it is more efficient to store a reference to the data rather than the > data itself. Image data can benefit from proximity to meta data that describes it that is in a relational database. You incorrect presumption is that one would want to make some kind of algebraic query against the binary data itself, when in fact quite often we merely want to retrieve the data due it's relevance to some other field upon which a query has been made. > Putting database data in the database needlessly increases load on the > database. If you are using MySQL, the tables in which the bitmap is stored > are read-locked during the read of the data. If the data is large, it can > use up buffering resources otherwise used to increase query performance. Putting image data on the filesystem when it has related fields in the database needlessly increases the load on the complexity of the application. > Bitmap image data can not be incorporated into the HTML stream with the > rest of the data retrieved. A reference must be created in the HTML > document so that the client web browser can issue a new HTTP request for > the image. It is more efficient to put a reference in the database and > have the browser query directly for the image against a file based system. Filesystem data cannot be directly incorporated into the browser request when a custom authentication system is in place that requires wrapping the file request in a PHP script. Your argument keep going back to the same refuted point. YOU CANNOT ALLOW DIRECT REQUESTING OF SENSITIVE DATA. > SQL databases don't use normal data access methods to access large binary > data, in PostgreSQL TOAST is used, in MySQL they are read as their own > data blocks, and in Oracle they are sometimes put in different table > spaces. Anyway you slice it, they are less efficient than normal "data." Once again you speak of one kind of efficiency. There are many kinds of efficiency when practicing computer science. Probably you think we should go back to directly programming in 1's and 0s because the efficiency of the code is superior to that generated by a higher level compiler. Puhlease. Did you actually study computer science? > If you can't come up with a scenario that disproves the previous > assertions, then you aren't arguing the point and creating strawmen in an > effort to avoid the real issues. I've come up with plenty of examples. You have chosen to ignore them. I also left an open challenge to you on an implementation basis that you have yet to accept. Feel free to study up on self-deception. Your critical thinking appears to fall into this category: http://en.wikipedia.org/wiki/Self-deception > >> > However, none of those posts answered
Re: [PHP] Re: pictures stored in PostgreSQL DB
On Monday 05 March 2007 19:14, Robert Cummings wrote: > On Mon, 2007-03-05 at 10:16 -0500, Mark wrote: > > Alain Roger wrote: > > > Hi, > > > > > > It's amazing that my previous post has raised so much consideration > > > about the fact to store or not pictures into DB. > > > > And yet you ask again!? Did you not learn? No good can come from this > > question. > > He didn't care about the debate. He is already using a database and > wants to display the images. I'm sure he learned plenty, but not what he > wanted to learn. I'd say the most important outcome of the side-track > debate was to clarify that it depends on what you are working with, what > you are doing, what your tolerance is for various types of solutions, > and where those tolerances lie. An important thing we also learned, is > that while filesystem storage is often the better solution, it is not > always the best solution, especially when factoring in such things as > convenience and simplicity. > > > > However, none of those posts answered to my question... How can i > > > retrieve and display those pictures to my PHP pages ? > > > > > > Basically, on my PHP page I have some texts and I would like to extract > > > from DB the pictures to display. > > > Therefore, set the header to mine JPEG or GIF does not allow to have > > > text also. > > > > This is another problem with images in databases, unlike text or data > > which can be incorporated into the HTML output stream, an image needs to > > be its own file. > > Image doesn't need to be it's own file, if it did then it would be > forced to be on the filesystem, since we know it can be in a database > instead, it thus follow it does not need to be it's own file... Ah but > you are going to say "but it needs it's own script to access the image!" > but that is not so, since a front end controller style script could > easily contain the code to display an image with a little switch > statement. Either way, you need a script wrapped around serving images > from the filesystem if those images need to be protected by your site's > authentication. Thus the point is completely moot. > > > You will have to hit the database twice. Once to render the page, and > > again to render the image. > > > > To render the image you need to query the database and send the data back > > on its own, but before you do, you have to set the content type header to > > jpeg, gif, or whatever. > > > > This is why I say image data does not belong in the database. > > Boring. Belongs wherever the developer or the business > requirements want to store it. Once again, you will need to set the > content type header anyways if you have wrapped the image serving in > your site's authentication checks -- whether it resides on the > filesystem, in the database, or in a dark place where the sun don't > shine. > > > > So please, how can i do to display pictures from DB, when my PHP page > > > also include texts and other images (from filesystem) ? > > > > > > In fact i would like to do something like a thumbnail... > > > > You will need to repeat the same steps outlined above, but use image > > manipulation utilities to reduce the image. Again, that's why you store > > images in files and not in the database. > > Wrong again. Can pull the image directly into memory from the retrieved > database field. Can then convert it to an image resource using > imagecreatefromstring(). Can manipulate the image directly in memory > using the image manipulation functions. And finally, can directly flush > the image to the browser without ever having touched the filesystem > manually. Filesystem is not a necessity. I picked up on that link, very interesting reading. Just a lot of fuss making the scaling function work, wheras I got pnmscale doing it for nothing. But I really liked the _clean_ solution fetching images from database and rescale on FREAKY!!! ;D *but slow* And even when I now seldom use the database to store images, I found even more areas to implement the idead you put me on... thanks > > Cheers, > Rob. > -- > .. > > | InterJinn Application Framework - http://www.interjinn.com | > | > :: > : > | An application and templating framework for PHP. Boasting | > | a powerful, scalable system for accessing system services | > | such as forms, properties, sessions, and caches. InterJinn | > | also provides an extremely flexible architecture for | > | creating re-usable components quickly and easily. | > > `' -- --- Børge Kennel Arivene http://www.arivene.net --- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: pictures stored in PostgreSQL DB
> On Mon, 2007-03-05 at 10:16 -0500, Mark wrote: >> Alain Roger wrote: >> >> > Hi, >> > >> > It's amazing that my previous post has raised so much consideration >> about >> > the fact to store or not pictures into DB. >> >> And yet you ask again!? Did you not learn? No good can come from this >> question. > > He didn't care about the debate. He is already using a database and > wants to display the images. I'm sure he learned plenty, but not what he > wanted to learn. "I gained nothing at all from supreme enlightenment - and for that very reason, it is called supreme enlightenment" Buddha. > I'd say the most important outcome of the side-track > debate was to clarify that it depends on what you are working with, what > you are doing, what your tolerance is for various types of solutions, > and where those tolerances lie. An important thing we also learned, is > that while filesystem storage is often the better solution, it is not > always the best solution, especially when factoring in such things as > convenience and simplicity. I don't think we came to any such conclusion. I still assert that while there may be multiple "right" ways to accomplish a task, there are often clearly "wrong" ways. Putting bitmap data inside the database is a mistake. Before y'all got hyper-literal trying to argue the finer details of the definition of "mistake," my assertion is this: I have yet to see one implementation or strategy where putting bitmap data in a database can not be accomplished more efficiently using a different approach. Bitmap data does not belong in a SQL database because it is not something that is of any use to the algebraic relational syntax of SQL, thus it is more efficient to store a reference to the data rather than the data itself. Putting database data in the database needlessly increases load on the database. If you are using MySQL, the tables in which the bitmap is stored are read-locked during the read of the data. If the data is large, it can use up buffering resources otherwise used to increase query performance. Bitmap image data can not be incorporated into the HTML stream with the rest of the data retrieved. A reference must be created in the HTML document so that the client web browser can issue a new HTTP request for the image. It is more efficient to put a reference in the database and have the browser query directly for the image against a file based system. SQL databases don't use normal data access methods to access large binary data, in PostgreSQL TOAST is used, in MySQL they are read as their own data blocks, and in Oracle they are sometimes put in different table spaces. Anyway you slice it, they are less efficient than normal "data." If you can't come up with a scenario that disproves the previous assertions, then you aren't arguing the point and creating strawmen in an effort to avoid the real issues. > >> > However, none of those posts answered to my question... How can i >> retrieve >> > and display those pictures to my PHP pages ? >> > >> > Basically, on my PHP page I have some texts and I would like to >> extract >> > from DB the pictures to display. >> > Therefore, set the header to mine JPEG or GIF does not allow to have >> text >> > also. >> >> This is another problem with images in databases, unlike text or data >> which >> can be incorporated into the HTML output stream, an image needs to be >> its >> own file. > > Image doesn't need to be it's own file, Again, don't get hyper-literal, by file, as used in this post, I meant file as seen by the browser which is represented by a URL and causes a HTTP request. [snip] > >> You will have to hit the database twice. Once to render the page, and >> again >> to render the image. >> >> To render the image you need to query the database and send the data >> back on >> its own, but before you do, you have to set the content type header to >> jpeg, gif, or whatever. >> >> This is why I say image data does not belong in the database. > > Boring. Actual answers to actual problems are usually boring. > Belongs wherever the developer or the business > requirements want to store it. Yea, and 1+1 = what ever the engineer or the business requirements want it to be, right? This is engineering, not art class. There are ways to evaluate solutions as being better than others. [snip] > >> > So please, how can i do to display pictures from DB, when my PHP page >> also >> > include texts and other images (from filesystem) ? >> > >> > In fact i would like to do something like a thumbnail... >> >> You will need to repeat the same steps outlined above, but use image >> manipulation utilities to reduce the image. Again, that's why you store >> images in files and not in the database. > [snip] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: pictures stored in PostgreSQL DB
On Mon, 2007-03-05 at 10:16 -0500, Mark wrote: > Alain Roger wrote: > > > Hi, > > > > It's amazing that my previous post has raised so much consideration about > > the fact to store or not pictures into DB. > > And yet you ask again!? Did you not learn? No good can come from this > question. He didn't care about the debate. He is already using a database and wants to display the images. I'm sure he learned plenty, but not what he wanted to learn. I'd say the most important outcome of the side-track debate was to clarify that it depends on what you are working with, what you are doing, what your tolerance is for various types of solutions, and where those tolerances lie. An important thing we also learned, is that while filesystem storage is often the better solution, it is not always the best solution, especially when factoring in such things as convenience and simplicity. > > However, none of those posts answered to my question... How can i retrieve > > and display those pictures to my PHP pages ? > > > > Basically, on my PHP page I have some texts and I would like to extract > > from DB the pictures to display. > > Therefore, set the header to mine JPEG or GIF does not allow to have text > > also. > > This is another problem with images in databases, unlike text or data which > can be incorporated into the HTML output stream, an image needs to be its > own file. Image doesn't need to be it's own file, if it did then it would be forced to be on the filesystem, since we know it can be in a database instead, it thus follow it does not need to be it's own file... Ah but you are going to say "but it needs it's own script to access the image!" but that is not so, since a front end controller style script could easily contain the code to display an image with a little switch statement. Either way, you need a script wrapped around serving images from the filesystem if those images need to be protected by your site's authentication. Thus the point is completely moot. > You will have to hit the database twice. Once to render the page, and again > to render the image. > > To render the image you need to query the database and send the data back on > its own, but before you do, you have to set the content type header to > jpeg, gif, or whatever. > > This is why I say image data does not belong in the database. Boring. Belongs wherever the developer or the business requirements want to store it. Once again, you will need to set the content type header anyways if you have wrapped the image serving in your site's authentication checks -- whether it resides on the filesystem, in the database, or in a dark place where the sun don't shine. > > So please, how can i do to display pictures from DB, when my PHP page also > > include texts and other images (from filesystem) ? > > > > In fact i would like to do something like a thumbnail... > > You will need to repeat the same steps outlined above, but use image > manipulation utilities to reduce the image. Again, that's why you store > images in files and not in the database. Wrong again. Can pull the image directly into memory from the retrieved database field. Can then convert it to an image resource using imagecreatefromstring(). Can manipulate the image directly in memory using the image manipulation functions. And finally, can directly flush the image to the browser without ever having touched the filesystem manually. Filesystem is not a necessity. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: pictures stored in PostgreSQL DB
Alain Roger wrote: > Hi, > > It's amazing that my previous post has raised so much consideration about > the fact to store or not pictures into DB. And yet you ask again!? Did you not learn? No good can come from this question. > However, none of those posts answered to my question... How can i retrieve > and display those pictures to my PHP pages ? > > Basically, on my PHP page I have some texts and I would like to extract > from DB the pictures to display. > Therefore, set the header to mine JPEG or GIF does not allow to have text > also. This is another problem with images in databases, unlike text or data which can be incorporated into the HTML output stream, an image needs to be its own file. You will have to hit the database twice. Once to render the page, and again to render the image. To render the image you need to query the database and send the data back on its own, but before you do, you have to set the content type header to jpeg, gif, or whatever. This is why I say image data does not belong in the database. > > So please, how can i do to display pictures from DB, when my PHP page also > include texts and other images (from filesystem) ? > > In fact i would like to do something like a thumbnail... You will need to repeat the same steps outlined above, but use image manipulation utilities to reduce the image. Again, that's why you store images in files and not in the database. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
