This is OK when we only have one web server but as is the case for our maiden voyage of the CMS, the cms will be on 2 web servers.
Here's where I go out on a limb and suggest that unless you have big reasons not to, you should really consider storing all the images and flash files in a BLOB column in your database. Why? 1) You don't have to manage NTFS (or whatever the file server) permissions. 2) The process for deleting a image BLOB is to simply delete the row (no extra process to delete the file from the file-system). 3) There is no chance to get out of sync as to the name and location of the attachment between the SQL table tracking it and the file-system. 4) The backup process is to "just backup the database". You don't have to coordinate the backup of the file system as well. 5) The restore process is to "just restore the database". The restore is atomic, not something you have to manually sync up. 6) The locality of the BLOB to the SQL rows means that you actually do much less disk-seeking on the machine (if storing both on the same server/SAN). 7) You can cluster the SQL servers for redundancy... if you needed to get redundancy for the file-system approach you would need to do a shared file-system SAN and a clustered file server. 8) You can transparently use partitioned views/indexes to move stale documents to another SQL server that would have much smaller transaction logs. [ see http://www.sqlteam.com/Item.ASP?ItemID=684 and http://www.sqlteam.com/Item.ASP?ItemID=751 ] To address common concerns: 1) You can put the images in a seperate table linked via foreign keys, and then place that table in its own table-space. This also keeps people from "accidentally" doing a SELECT * and sucking in the BLOB column. 2) The backup size for the SQL server is larger, but not much larger than the backup of both the database and the files (and subdirectory data) from the file-system would be (and you should be backing them up in synchrony). If this is a huge concern, the document table and its BLOBs could be moved to a separate database and that can be backed-up at a different schedule. 3) The transaction logs will be larger, but only insofar and in proportion to the number of documents INSERTed or UPDATEd. It is thus important to make sure your SQL backups do log truncation a little more often than you might otherwise need. 4) Replication is actually very easy this way... you don't need any other daemon process to ship the file-system files over, you don't need a SAN, you don't have to cluster. If you really want, you can use log-shipping to send everything to various geographically disperate Just as an aside, Microsoft uses BLOB storage for the SharePoint Servers, for Team Foundation Version Control and for TerraServer (purported to be the largest single database in the world--its all the satellite photos you see in maps.live.com). They seem to think it's the way to go... <Dennis Miller>Of course this is just my opinion, I could be wrong</Dennis Miller> [This has been a recording of a previously aired conversation first heard on the Windows Off-Topic mailing list] -- "We do not have the luxury of making that risky assumption that people will not be affected by the potential change. I know this can be frustrating for you as it is for us. Thanks for your understanding in this matter.." --Some misguided soul at Microsoft Marc C. Brooks http://musingmarc.blogspot.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
