This one time, at band camp, "John Francis" <[EMAIL PROTECTED]> wrote:
> > > > revised feature list.... > > Mostly looks very good, but ... > > > Files in database > > Assuming this means the actual image pixels will be stored in the > database, not in regular files & folders; this is, IMO, a bad idea. > > Quite apart from the "all your eggs in one basket" principle, this > will increase the number of times each byte of data has to be touched. > (It will also make backups an expensive process, as adding even just > one new image may well necessitate saving the whole database again). Storing files withing the filesystem is also all the eggs in one basket. Some may argue that the image files could be stored on a seperate partition of drive, but the same could be said of the database. the database could be on a seperate server, which is often the case. Backups do become intensive, and utilities like rsync become redundant for this purpose. However a simple sql dump can be done in a small amound of time and saved in timestamped order. This could be done each 24 hours out of cron if required. The value of storing images/binary data in the database is a central point of backup makeing them less cumbersome. The major benifit is referencing data. If the data about the image is stored in the database and the image stored in the filesystem, the integrity of the data cannot be guarenteed. You could write an integrity checker and have it run from cron and notify you if there is a failure of referential integrity, but then you would need to hack alot of code to and build up much overhead from the filesystem, which is what we are trying to avoid. The major benifit is portability. The use of a single SQL dump versus the backing up both the database and the filesystem component. Backing up the filesystem and the database would cause huge backups itself and then you have the problem once more of wrestling with referential integrity. For those concerned about access speeds, here is a little benchmark I put togther using ApacheBench http://220.240.55.75/image_in_database/ If you wish to see images in a database at work in a production envioronment, take a look at http://terraserver.microsoft.com/default.aspx This database holds over 250 million images in BLOBs (Binary Large OBjects) > o I'd use CGI (probably just PHP or Perl) to generate the HTML > handed off to the server. Yes, I will be using PHP5 as it has wonderful new OO features, and is will be deployed on many servers when released. This will give greater flexibilty to the application and greater speed. Thanks for your feedback Kind regards Kevin -- ______ (_____ \ _____) ) ____ ____ ____ ____ | ____/ / _ ) / _ | / ___) / _ ) | | ( (/ / ( ( | |( (___ ( (/ / |_| \____) \_||_| \____) \____) Kevin Waterson Port Macquarie, Australia
