Hi -
At some point, fiddling with an FTP application no longer makes sense.
If this is an application that's going to be used by a client in a
production environment, I'd probably argue that it doesn't make sense at
all.
When your application scales to some critical point, you'll find
yourself in a position where either re-entering images via your UI for
small jobs, or implementing some image manipluation technique for larger
problems makes the most sense.
When your dataset is small, it probably doesn't matter -- but if your
dataset does become larger, and I'm thinking even a couple thousand
records, it's probably easier to just build a good management tool, and
use it. By the time I've fired up my FTP app, logged in, navigated to
the right directory, located the file I want and swapped it out, I could
probably have just used the web tool I built.
Plus, if this is in production, there's the potential issue of file
ownership and permissions. You don't want a support call six months
later because the end user can't update the image you uploaded via FTP.
If you're processing file uploads from the browser via PHP (I would),
and the FTP user owns the file instead of the Apache user, you've got a
problem -- and one that your client's invariably going to want to have
fixed RIGHT NOW. (and of course, it'll come up when you're on the 11th
hour of a deadline for another client)
I can appreciate the need to separate images into manageable directory
sizes -- this can definitely simplify backing up or migrating data,
especially if your dataset grows large enough to span multiple disks.
The thing that I would caution against, would be relying on the "100
image" assumption in your application logic.
Looking at the directory size during the image creation process is
totally cool.
Using application logic to "find" your image, rather than associating
the path and filename directly with the database record is another
thing, and I would argue that you *really* want to avoid doing that.
The cost of associating a hard path and filename with your image record
is very low, and should you find (or find an urgent, dire need for) a
better scheme for handling your images later, you won't have a huge
migration headache on your hands.
Best,
Jeromie
>If the site is larger, (more than about 500 properties), I divide the
>images folder into subfolders, each of will hold 100 properties. It's
>easy enough for PHP to do the calculation to find out which folder the
>image will be in.
>
>Folder images/0000 holds images for properties 0 to 99
>Folder images/0001 holds images for properties 100 to 999
>
>Although I do know that some people just bang all the images into one
>folder, it then becomes a pain if I want to use my FTP program to fiddle
>with something, because it only returns 2000 (?) files at once.
>
>
>
>>What about a
>>million images?
>>
>>
>
>Then I will get someone else to figure out,
>I will be able to afford it... <G>
>
>
>
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/
