<snip...>
For the record, I will *never* say one size fits all in the realm of
computer programming...
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.
What does the DB approach offer that a centralized image server could
not? Still making network requests for some resource (in this case an
image)
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.
Very true, transactions and rollback capabilities would keep things in 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?
Again, thinking of a RAID Array for a centralized image server, with
potentially N hot standbys doing occasional rsyncs. So, this
consideration is not quite as strong as others... And we all know
customers can be idiots, so drawing conclusions on what they deem
important is not a strong consideration either.
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.
Hmm... coder stupidity...can happen with any system you implement. So
it's a draw on this one.
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.
Yeah, the future...
I guess memory is getting cheaper every day. But there is still a
capacity for a given machine. So, how easy would it be to scale DB
servers across multiple machines as opposed to having a centralized DB
server pointing to image locations potentially serviced by N image servers?
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.
Yep, but how many companies do you know of *today* that would scrap $5
million in computers to upgrade them all at a cost $x as opposed to just
spending another $25K to expand their current base? So as long as the
best bang for the buck today line of thinking holds...distributed
systems will remain dominant, especially in the area of data storage.
Overall this has been a cool and interesting thread. For the most part,
I would say I side with Mark, but again the fatal flaw appears to be the
insistence that one approach is right in 100% of the time...which 99% of
the time is false.
-B
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
