Re: [PHP] Re: how to display images stored in DB*

> 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.
.