> 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.
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."
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.
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.
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.) :-)
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.
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.
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.
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?
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.
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.
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?
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.
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.
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.
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.
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.
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.
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?
Cheers,
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
