>> > At 10:01 AM -0500 3/1/07, markw@xxxxxxxxxxxxxx wrote: >> >>> If you are open to honestly consider, then I shall provide a couple >>> of examples. But if I do and you do not agree, then your only >>> recourse will be to *prove* otherwise. >>> >>> So, what say you? >> >>Absolutely, I'm all about computer science. Give me some real world >>examples and I'll show you the flaws. >> >>-snip- >> >>What do *you* say? > > Mark: > > Well... it's not just me, but from what I've learned and read over the > years. > > Your claim is that in ALL cases using a file system to store images > is preferable to using a database. As such, you claim that using a dB > for storing images is "bad" practice. That is fairly close to my professional opinion, yes. There is, of course, always the exception to any rule, but in general, I would call storing bitmaps in a database without a damn good reason, a bad practice, yes. > > My claim is that both methods have their advantages and > disadvantages, as I said in my opening post on this thread "Both > techniques have up-sides and down-sides -- and I use both depending > upon needs." I would say that the error is that you weight each approach equally, and that one is clearly a bad practice for the various reasons I have posted. > > Part of the problem here is that we are using subjective terms such > as "bad" practice and "preferable" methodologies. So a bit of > objectivity is in order. Such terms can be viewed from different > perspectives, such as time taken, cost in equipment, ease of use, and > many other such concerns. One can not view the act of using a wrench as a hammer as anything but a bad practice. I'm sure at one time or another, we have all used a wrench as a hammer, but that in no way justifies an opinion that using a wrench as a hammer is appropriate. It may be necessary or convenient at some point in time, but not something one designs as a solution. > > However, I realize that what's "preferable" and "bad" practice for > you may differ for me and therein provides an opportunity for you to > pass on *proving* that none of the following fits within in your > considerations and restrictions. But, that's Okay -- you can keep > your opinion. I am only offering what I believe to be relevant > because you said you would honestly consider it. Hiding behind "opinion" is too easy. There are things that are better than others. Quality sucks in the software world largely because proper use of technologies is not understood. > > The following are the things I consider important for this discussion: > > Consideration 1 > > Storing images in a database bloats the database and you're more > likely to approach memory limits of your operating system. However, > storing images the file system, likewise may cause lookups to become > slower on some operating systems than using a dB (Granted this is a > weak consideration, but I read it, so it must be true.) :-) this is far too weak and unspecific to really address. "Bloat" is a subjective title. And "lookups to become slower" either encompasses failures of specific file systems or approach. > > Consideration 2 > > If your project is to supply images across several web servers on > different host, then you are caught in a sync problem. Images stored > in a file system must be stored on a local host. In a multiple host > situation you must have a duplicate set of images on each host. > Synchronizing images across different files systems on different host > is far more complicated and problematic than maintaining a single > database from which all host can draw the most current images. This is a complete fallacy. It fails on a few assumptions. (1) If you assume that you have one database supply all the images to all your servers, then you merely need to expose an "images.domain.com" URL that contains all your images. That will be faster and more efficient than a single database. (2) Again, assuming one machine supply all data, a back-end apache server serving images from one machine through a validated PHP pass through is still more efficient than a database. (3) Assuming that you want to distribute database images, there are many tools to accomplish this, not the least of which is rsync. > > Consideration 3 > > Storing images images in a file system and their location in a > database is a two step process in all image operations. If your > project requires a transactions, then it's obviously more difficult > to accomplish for not only do you have to do two operations, but they > must take place in two domains. Whereas, if you store images in a > database it is a simple matter to add, alter, and delete because it's > one operation and thus no need to confirm that the file system and > database remain in sync. This is a purely hypothetical and easily solved problem, if you can even create a scenario that would cause it. First of all, assuming a requirement of ACID transactions, one create the bitmap file name using something like a UID, save the bitmap to the disk using fsync() to ensure it is committed to disk, then update the database record. I'd like to point out that you are focusing on one aspect of a whole solution. Yes, this one aspect may take two steps in your code, but at best, it is unclear that it is any less efficient when compared to what happens at the database level, and we already know retrieving the bitmap is more efficient. > > Consideration 4 > > Even without transactions, it's simpler to have all data in a single > dB than it is two divide the data into two sets and then maintain a > sync. Simpler for who? It may take a little NRE do it right, but once it is done it is done. > > Consideration 5 > > Backups. It is far easier, faster, more reliable, and less prone to > error to perform a single mysql dump of all images than it is to > preform a mysql dump of all image locations AND duplicate all image > files. I even had a client who demanded that his image files be > localized in such a manner. That's a real world example, where's the > flaw in providing what the customer wants? The customer is usually wrong when it comes to technology. They may know, conceptually, what they want, it is your job to give them what they really need. To address the "easier" and "faster" issue, I'm not sure I can fully agree. Like before, "easy" is a little NRE away. "Faster" is debatable as the real issue is size of data and data transport. Also, if you are backing up and using MySQL with MyISAM you will be readlocking the table while reading data out of it and hurt performance of your database. > > Consideration 6 > > While this should be avoided through good coding practice, but if you > screw-up a path, things can get chaotic real fast. Hard coding > partial paths in your code and pulling the rest of the path out of > the dB is prone to more error than just accessing the image directly > from the database. Granted, coders should be aware that "all of the > path" should be taken from the dB and not hard code any path > information, but that practice isn't always followed. Unfortunately, > we don't always work with just "our" code and preferences. I can't accept "stupid programmers" as a reason. Stupid programmers can break anything. > > Consideration 7 > > The future -- while programming styles and types differ, the trend is > toward encapsulating (i.e., keeping all data, methods and functions > together within an organization and hidden). From OOP to unobtrusive > code, clearly this is the direction of today. This is too simplistic a view and you are grasping for straws and your know it. > > My personal preference is to keep all my relative data together as > well. If my data, along with other attributes, incorporates images > then, I like the idea (but, don't always practice it myself) of > having everything in one place and storing images along with other > associated data in a database makes sense to me. To me, images are > nothing more than large hunks of data. Why tell fat people to sit > somewhere else? That is a pretty simplistic view of data. There are classes of data that are different than others. It is funny, but most people don't get the fact that SQL databases are not the best way to store data. They are designed to select algebraic relationships from a data set. They are designed to ensure accuracy of the relationships and the integrity of the data. When you have data that does not need to be associated, queried, or hard linked to the relationships, the it doesn't make any real sense to use a SQL database. > > I certainly can understand and realize that images, because of their > size (and size alone), can be problematic with respect to time and > memory, however, both of those physical restraints are becoming less > of a limiting factor everyday. Ahh, th "computer are getting faster" fallacy, people have been using that for over 25 years and it still isn't true. > > Sure, programmers like to reduce the amount of memory their code > occupies, and reduce the amount of time it takes for their code to > execute, but in the final accounting, those considerations are > becoming less and less important each day. That simply isn't true. Every time you see a web site "slashdotted," remember the nonsense you are saying. > > For example, the threshold definition for a super-computer twenty > years ago has been surpassed by todays' common laptops. Likewise, > memory that cost $1k twenty years ago cost less than $0.01 today. > Surely, these trends toward faster and cheaper computing will > continue. To anticipate how these changes will affect programming is > certainly worth consideration today. Assuming requirements don't grow in unison. > > It is without doubt, in my mind, that the ease that dB's offer in > localizing data will prevail over distributive methodologies which > are primarily based upon time and money concerns -- for time and > money are lessening concerns. Again, next time you see a site "slashdotted" remember this. That sort of stuff happens exactly for the reasons you are promoting. > > We use dB's far more today than we ever have before and there are > many reason for this. In my opinion, they are easier, localized, > provide more function, becoming cheaper, and will probably prevail > over all data storage methodologies regardless of out-dated legacy > perspectives or misconceptions about the inherit problems that > accompany different data types. There is no doubt that the trend of database vs file systems is converging, each are getting features of the other, they are not there yet. > > In short, things change -- while the legacy lives on, we don't have > to use I, J, K, and L as counters as we did in FORTRAN. It may surprise you to know that there were other languages that could do more at the same time as FORTRAN's hayday. > > Now, if you want to continue this debate, all you have to do is to > *prove* each of the above examples as being "wrong" to support your > claim. :-) > > So, what say you? Done. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
