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

>> > At 10:01 AM -0500 3/1/07, markw@xxxxxxxxxxxxxx wrote:
tedd said:
>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,

Good, then we are agreed. There are exceptions to every rule. See that was easy. :-)

I realize that you obviously think in terms of absolute, but the world isn't like that. Everything, including the 1's and 0's in computing are not black and white, but rather meeting, or not, different thresholds.

"Bad" practice or "good" practice depends upon the needs and one's perspective of the situation. Take this email communication for example, we say what we want and we make our points, or not.

But, HOW we (as programmers) do it doesn't matter much from our perspective because it's basic communication. As long as one doesn't become too rude or present things that are totally wrong, everything (including making grammatical errors ) is considered "good" practice. Whereas if we were communicating on a writers list, then those types of errors would be consider "bad" practice. We live in a world of compromise.

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

No my friend, you are the one placing weight. I'm simply stating that both have advantages and disadvantages and that is true. Much like saying that the rule "one-way is always right" has exceptions and thus is false by definition.

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

We can argue semantics if you want, but a tool is still just a tool -- it's there to be used as we need. There are ways to optimize tool's use and one can define "good" or "bad" in those terms. But, those terms would are subject to the artificial perspective you are placing on their use.

For example, if you were being attacked, couldn't find a gun, and used a wrench instead to defend yourself I think that would show "good" practice of a wrench's use -- would it not?

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

It's not a question of hiding behind opinion, but rather defining the rules. If you use subjective terms then by definition they are subjective and not absolute.

Yes, a hammer is better than a wrench for driving nails, but the rule you are using is "tool design". The hammer is better at driving nails because it was designed for driving nails -- this is a "begging the question" type of rule.

However, if you change the rule, then the term "good" or "bad" changes as well. It's a matter of semantics.

Quality sucks in the software world largely because proper use of
technologies is not understood.

You see, those are opinions. You think that the quality of software sucks, whatever that means. But I take it that it doesn't preform to your expectations -- that's OK, but it's your expectations.

You also think that the reasons for this are that the use of technologies is not understood -- again, that's Okay, but it's still your opinion. Side note: Will Rogers once said "We are all ignorant, only in different subjects."

If you were to talk to the average computer user; or to the average investor who invests in technologies; or to the businessman who is paying the bills for programmers to build the product while trying to make money at the same time; they all might have different opinions as to the quality and state of software. Again, that would be their opinion -- and -- they would be correct from their perspective with respect to "good" and "bad" -- this is basic stuff. Weren't you taught this in college?

Seldom do any of us make "bad" choices when we know better.

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

Really? What I said was almost a direct quote taken from "MySQL Cookbook" by Paul DuBois" page 801. If I had to choose who to believe, I would go with Paul. Remember, I did say at the start of all this that my opinions were from my experience and from what I've read.

-----

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

Again, I'll go with Paul on this one as well.

------

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

Simpler for whom? (Good thing we're not on a writers list, huh? ) :-)

Simpler for me and from my perspective (i.e., my rules) it's "better" for me. Do you see how this "I make the rules" thing works?

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

My job is to do what my clients want. Sure, I try to educate and guide, but sometimes they don't follow. Try making a client's web site conform to section 508 or w3c compliance issues when he's not concerned about paying for those.

Now, what should a programmer do in that situation, One could say it would be "bad" practice to do what they want. But, my family could also say it would be "bad" practice for me not pay the mortgage. Again, the "badness" of the act depends upon perspective.

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

The point was not stupid programmers, but rather using a dB instead of the file system removed one possible source of error. Even "good" programmers make "stupid" mistakes -- I certainly have. Don't you?

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

No, I disagree -- I'm not grasping at anything. It's clear that this is the trend. Don't you see 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.

Simple works for me. I actually try to keep things simple -- it makes for "better" programming. :-)

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

There you go with the "best" thing again. "Best" is a subjective term.

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

It may not make any sense to you, but to me it does.

Besides, a file system is just an organized association of data as well, isn't it? It's like a bare-bones dB, if you will.

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

Have you ever seen "Jon Stewart" of the Daily Show --

http://www.comedycentral.com/shows/the_daily_show/index.jhtml

-- when he does a "double take" and says "Whaaaaa?" and rubs his eyes and repeats?

Are you saying that computers are NOT getting faster? Now, I'm not saying that these little critters are running across your office floor much faster than they did yesterday, but rather they are actually processing operations faster. This is not a fallacy -- computers are processing data faster than ever before.

As a result, programming is changing. We did not have the processing speeds (nor memory) to make OOP work 30 years ago. And I am sure there are new technologies not yet dreamed that will emerge as the result of even more speed and memory.

So, your statement is false, obviously false, and most positivity false. I can't imagine anyone even saying it. Oh well, it takes all types.

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

What isn't true? That programmers like to reduce the amount of memory their code occupies -- in other words, make their code more compact. OR, that programmers try to reduce the time that their programs to execute -- in other words make their code run faster.

I don't know about you, but I do that every day that I code. I am always concerned about speed and size -- however, I realize that my concerns for programming compact and speedy code are becoming lessened by faster and larger computers.

------

Every time you see a web site "slashdotted,"
remember the nonsense you are saying.

I don't see the relationship between writing efficient code and slashdotted -- you lost me there.

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

You missed my point.

Faster and cheaper has allowed opportunities (or the "glass half-empty" requirements) to grow.

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

Again, I don't see what you are talking about.

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

I didn't say that we were there. I made the suggestion that both (fs and dB) will eventually merge. Either the file system will become a dB, or dB's will just take over -- the end result will be a more intelligent file-system or just a dB.

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

No, that doesn't surprise me -- before FORTRAN I used to program with rocks. And that was before someone invented zero. You try programming with just ones and see what you can do. :-)

Cheers,

tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
.

Relevant Pages

  • Re: [PHP] Re: how to display images stored in DB*
    ... Your claim is that in ALL cases using a file system to store images ... bitmaps in a database without a damn good reason, a bad practice, yes. ...
    (php.general)
  • Re: bound object frame: picture
    ... Please let me respond to your critique and hopefully help Bob along the way. ... generates can be very large when they contain images. ... Print event NOT THE FORMAT EVENT. ... your entire database will stop working when you get about 100 pictures ...
    (microsoft.public.access.forms)
  • Re: ListView - Caching Thumbnails?
    ... The program just will yield some odd results if they do (which I figure they can deal with if they are monkeying with the database;). ... Access databases fill the middle ground I guess but still, you can edit XML by hand. ... The underlying goal here is to create an interactive anatomical atlas program using high resolution images. ... Then I go back to school ). ...
    (microsoft.public.dotnet.languages.vb)
  • Re: bound object frame: picture
    ... Keeping the Images in a folder instead of the MDB is certainly the ... If you follow the above steps and your Report still fails then here are ... The error message is "Database has reached maximum size". ... > I have tried splitting the database, linking tables from additional databases, and finally not linking the photos but only storing the text description of the path to the photo file in the database. ...
    (microsoft.public.access.forms)
  • Re: Outlook Express question
    ... > This message is for Robert Aldwinckle as well. ... > I've tried using OllyDbg to step through it. ... or the programmers took a fancy for the ... images that you noticed. ...
    (microsoft.public.windowsxp.general)