>> > 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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
