> On Mon, 2007-03-05 at 14:48 -0500, markw@xxxxxxxxxxxxxx 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 access images. One could store in the local session data a variable "allowed" = "/images/filename" and rerieve the image. That way it authenticates locally and saves a database hit. The PHP file can simply do an fopen of the bitmap and send it back. > >> 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? You didn't actually address the subject, you merely made an absurd claim that I would say something stupid and called that debate. I did in fact, study computer science, and besides a few software patents and published writings, I study constantly and get paid to advise. So, are you going to actually debate, or simply ad hominem through this? > >> 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. None that actually show a need. An alternate implementation that is provably less efficient does not disprove he assertion. > You have chosen to ignore them. Absolutely not, I analyze them and tell you why they don't work as well. > 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 I apologized earlier for coming off as a wise ass, and I now remember why I did that. Discuss the facts and methods please. > >> >> > 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. > > Again, please stop being hyper ignorant. Your files require an http > request even when not protected by any kind of authentication. And when > they do require authentication, then quite likely they require a > wrapping PHP script (or other scripting language) and access to the > database server to determine the validity of the authentication. Using a PHP script to verify authentication is a good way to accomplish the task, but that has nothing to do with storing bitmap data in a database. >> > >> >> 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. >> > >> > Boooooooooooooooooring. >> >> Actual answers to actual problems are usually boring. > > No, what is boring is they way you reject anything that challenges you > and pretend to not have heard of any evidence to the contrary of your > argument. Statements are not evidence, statements verified to be accurate are. > >> > 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? > > 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. And that shows the depths of your participation in this discussion. There is a canonical meaning to words, phrases, and expressions. When one does not wish to listen, one merely ignores these making productive discussion impossible. Done -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
