I was thinking about saving some files in a SQL Server DB and then reading those back to the client for download. Any warnings that I should know about before doing so? The files will generally be at most 2mb in probably .pdf format. I've heard bad things about doing this in Access...but then again, SQL Server isn't access.Just my humble opinion here, but I'd suggest putting ONLY the paths (and/or filenames) to the files in your database fields... that way, it makes the database less bloated and you can then point to the files in your code, using the path returned from the database queries.|||Good point. I considered that: but here's my question for that idea.
Would it take up more server space if I were to place the file in the db, or as a file on the server with a path in the db? I'm trying to conserve the most amount of space as this will eventually grow to a reallly really large amount of files. And that's alot of money on some hosting sites.
Side note: I remember you responding to a problem I had about a year ago...random memory thing.|||One vote for saving the path. It's much less effort to get it out to the user. Don't have to mess with getting it out of the database. Same amount of bytes either way, so I think the storage space is probably comparable. The difference is probably just whatever overhead difference there is between NTFS and the DB to keep track of it.
Your database backups will be much bigger. If you have files in the database, the miscellaneous files in your site, and your database backups, then your images are really there twice. Once in the database, once in your disk backup. Rather than a path or filename in your database and the images on disk. I think that would be much more space. Don't know what the backup arrangement would be, but it might be a consideration.
I can't see it negatively impacting space and the ease of use is much better when stored in the file system.
No comments:
Post a Comment