>You mean that I shouldn't look up the property reference in the database, and
>calculate the path to the image from that? I have never
>had any problems with moving or amending, I can't visualise why or how I would
>have problems.
>
I personally wouldn't calculate the path to the image as a method for
constructing the target URL. It's one way to go about things, and there
probably isn't anything that's going to hose you -- but it does add
complexity to your logic that doesn't need to be there.
Concatenating two columns from a database record is a much more
straightforward proposition and would most likely be faster from an
execution standpoint. The most important thing though, IMO is that
concatenating two strings into an image path is going to be immediately
recognized and understood by any programmer that comes along after you
(even the junior, junior, junior ones), whereas calculating the path
might not be so obvious.
For storing records, I totally see where you're coming from. Since
you've taken the time to calculate the location of the file during the
storage process, save the result of the calculation (in the form of the
path/directory) in the database. This saves you the cost of calculating
the path on the access -- which hopefully occurs more frequently than
your writes -- and since you're already hitting the database for the
filename, you're essentially getting the directory for free.
>I also sometimes put the URL in the database, if there are going to be images
>on different servers. I can't see the difference, to be honest.
>
>
Storing the entire URL is probably overkill (and would suck if you wanted to
change a hostname later), but a column for the image name and a column for the
chunk of the path that is assigned would be the way to go IMO. You could
always go back and add a hostname column later, if the requirement came up that
you needed to branch images off to multiple servers.
>The database tells me where the image is, in both examples. The first method
>just has smaller databases, the second can handle more complex
>paths to the images.
>
You're probably right, especially in the context of the app you're
building. It's a nitpicky thing, and PHP and MySQL are fast enough that
you're not going to see much of a difference until you're looking at a
large load. I really like your notion of keeping the filesystem
human-friendly even though you're automatically generating all of these
files. I can think of a couple situations where it would be handy in a
pinch.
My point is that you can have your cake and eat it too. Encapsulate the
complexity of the path calculation in the storage method, then store the
result in the database. Now you've only got one complicated part, and
you've only got to do the calculation once. The method that retrieves
the data (getter) can now be totally brain-dead. Now you're reducing
the opportunites for bugs down to the bare minimum, and you're moving
the heavy lifting from the most frequently called method (the getter) to
the most infrequently called method (the setter) in the application.
Best,
Jeromie
The php_mysql group is dedicated to learn more about the PHP/MySQL web database
possibilities through group learning.
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/php_mysql/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
