In message <[EMAIL PROTECTED]>, Jeromie Clark <[EMAIL PROTECTED]> writes >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.
In my application, it is only for emergency fixes, and is rarely used. But when I want to use it, I am able to do so. I feel more relaxed if I can reach all the files simple when I need to, because I can guarantee that when I need to, I need to do it quickly. >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. That is the main logic behind it. >The thing that I would caution against, would be relying on the "100 >image" assumption in your application logic. Not 100 images in my example, it was 100 properties. The images for property 1 could be 1_1.jpg. 1_2.jpg, etc., and sticking to 100 properties means in practice, less than 2000 images per folder. Don't forget, not every property has the same number of images, so 'images per folder' would be really complex. >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. 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. And this from someone who learned about future proofing the hard way, moving from Access and ASP to a Proper Programming Language. I also used to use alphabetic codes for record IDs, and soon learnt the problems involved in upgrading there. so for the last few years, I have been very aware of two things whenever I design a system - future upgrades, and emergency fixes. 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. 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. -- Pete Clark Free advertising for your website, business, or organisation at: http://www.hotcosta.com/resources.php 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/
