Hello all and thanks in advance for any feedback. I'm working on a site that will allow users to upload files that should only by visible by a subset of users. I understand there to be two approaches. (1) Upload an actual file and place it in an actual directory on the webserver or (2) store the uploaded file as binary data in a database. Has anyone implemented a similar solution on discountasp.net or anywhere else? What is the most widely used mechanism for controlling access to uploaded files? Thanks.
Store the images in the file system for sure. Why? Here is a list of reasons (this comes from www.aspfaq.com/show.asp?id=2149) Keep images on the filesystem, and the location and other data in the database 1. if there is any chance that you will migrate to a different database platform, your current BLOB format might be incompatible with, or at least a pain to convert to, the new format -- since, like web browsers, each vendor has implemented things with their own slant. 2. when your database really goes south, to the point where even the backup is useless, you still have the files on the filesystem (though their usefulness is questionable, depending on how much related data was kept in the database). Which is arguably better than losing all of your data *and* all of your files. 3. having the images in the file system allows you to access the images from many different standard applications (FTP, web browser, etc) without having to write application code to pull the data out of the database, since you can't just 'SELECT image FROM table' and have the image appear in Enterprise Manager or Query Analyzer. 4. with some databases, e.g. Access and MSDE, the data inside is limited to 2 GB per database. SQL Server 2005 Express Edition supports 4 GB. The file system is only restricted by the size of the volume. Also, most hosts charge a significant fee for SQL Server storage space, so in that case it would be cheaper to store them in the file system, since there is far less premium on that space. 5. in SQL Server 7.0, when a table has an IMAGE or TEXT column, a page is reserved for every row, whether or not that column has any data... so if you don't have an image for each record, there is potential to have a lot of wasted space. There are workarounds to this, of course, such as splitting the image data into its own table with a foreign key to the main table. SQL Server 2000 *can* combine multiple images < 8kb on one page (but typically, high-volume sites with plenty of images are not focusing on file sizes < 8kb anyway). Also, in SQL Server 2000, if your images are less than 8kb, you can use the text in row option by running the following code: EXEC sp_TableOption N'TableName', 'TEXT IN ROW', 'ON' Of course you will have to be careful with this option if you have other TEXT / IMAGE columns in the table. 6. performance wise, including an <IMG SRC> tag generated by the database and pointing to a file that already exists is going to be faster than pulling the file out of the database, generating a temp file on the web server, and streaming that to the user. Also, table scans take more resources when there is an image datatype as opposed to a varchar that simply holds a 'pointer' to the file's location. 7. can be quite complicated extracting images, say from an Access database, since it adds OLE header info to the file (see KB #175261). With SQL Server it's not so bad; see KB #173308 for an example that works right out of the box, KB #258038 for a VB example using ADODB.Stream, and KB #194975 for samples that use ADO's GetChunk and AppendChunk methods. 8. The number of KB articles involving BLOB/IMAGE columns in SQL Server is astounding. Here is a brief subset: KB #152805, KB #162032, KB #164972, KB #170296, KB #171369, KB #177067, KB #177114, KB #187966, KB #192489, KB #193640, KB #195530, KB #195539, KB #197043, KB #198487, KB #207396, KB #217102, KB #223758, KB #230044, KB #244962, KB #254253, KB #252948, KB #255632, KB #257767, KB #263553, KB #271344, KB #272220, KB #276041, KB #280684, KB #286257, KB #298835, KB #308775, KB #317670, KB #324432, KB #834604, KB #888494, KB #890759, KB #895203 So, this should give you some idea of the number of problems associated with using the IMAGE datatype. Keep the images and associated data in the database 1. you can protect your images better with SQL Server and file system security, as opposed to simply file system. 2. it can be challenging to keep database and filesystem in sync with each other - if the record is deleted in SQL Server (e.g. through an ad hoc query, or a rollback) how does the file system portion of the application know to also delete the image in the file system? One approach is to use extended stored procedures in SQL Server to encompass the file system operations into the database transactions, however this can become as complex, or more so, than storing the BLOB directly in the database - which gives you greater transactional control and consistency. kevinasp.com
