Hello mailinglist! We are currently building a largish community-site, where users are going to receive diskspace to upload files and share with each other. Now we have to decide whether to put these files on the filesystem, or in the db as blobs. The pros and cons we have summed up so far is: --db-- faster than filesystem (according to some) easier to separate from the webservers, since they only need one datastorage that way easier to tie to userid and such damn big databasedumps --filesystem-- faster than db (according to some) easily handles big files extra complexity to tie users to filenames and directories outside the db Do any of you guys have any experience with this, or for that matter any instinctive reactions to the problem? regards, //Martin Kihlgren -- ################################################################### A woman is like your shadow; follow her, she flies; fly from her, she follows. -- Chamfort ###################################################################
Martin Kihlgren wrote:> Hello mailinglist! > > We are currently building a largish community-site, where users are > going to receive diskspace to upload files and share with each other. > > Now we have to decide whether to put these files on the filesystem, or > in the db as blobs. > > The pros and cons we have summed up so far is: > > --db-- > faster than filesystem (according to some) > easier to separate from the webservers, since they only need one datastorage that way > easier to tie to userid and such > damn big databasedumps > > --filesystem-- > faster than db (according to some) > easily handles big files > extra complexity to tie users to filenames and directories outside the db > > Do any of you guys have any experience with this, or for that matter > any instinctive reactions to the problem?In the PHP world I have done both options, on mysql and postgresql. I have slight preference for filesystem storage. Getting your db and database wrappers to play nicely with blobs, can be a little toughbut it might be trivial in Rails. And yes, your db backups become very big. It''s also nice to be able to ls through the files. I can hardly imagine storing and loading blobs from a db is faster. You have to encode/decode the whole thing and possibly load it from an external db server as opposed to just serving them directly or reading them in from a non-documentroot location. That said, we have a few production sites running that store blobs in the database and we generally don''t have any problems. And it is nice to not have to worry about folder permissions etc. HTH Jeroen
This topic comes up every month or so on this list, so search through the archives and you''ll find plenty of discussion of the pros vs. cons and various people''s opinions. A quick summary: - there are pros and cons (as you''ve already surmised) and no clear cut best/worst approach for all situations - in general most people''s preferences seem to come down to what they''ve done before, or how comfortable they are dealing with blobs vs. filesystem access in general - AFAIK, no-one''s released a killer plugin/engine to make one solution much easier/faster/simpler/better than the other. Regards Dave M. On 10/02/06, Martin Kihlgren <zond@troja.ath.cx> wrote:> > Hello mailinglist! > > We are currently building a largish community-site, where users are > going to receive diskspace to upload files and share with each other. > > Now we have to decide whether to put these files on the filesystem, or > in the db as blobs. > > The pros and cons we have summed up so far is: > > --db-- > faster than filesystem (according to some) > easier to separate from the webservers, since they only need one datastorage that way > easier to tie to userid and such > damn big databasedumps > > --filesystem-- > faster than db (according to some) > easily handles big files > extra complexity to tie users to filenames and directories outside the db > > Do any of you guys have any experience with this, or for that matter > any instinctive reactions to the problem? > > regards, > //Martin Kihlgren > > -- > ################################################################### > A woman is like your shadow; follow her, she flies; fly from her, she follows. > -- Chamfort > ################################################################### > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Feb 10, 2006, at 2:57 AM, Martin Kihlgren wrote:> Now we have to decide whether to put these files on the filesystem, or > in the db as blobs. > > The pros and cons we have summed up so far is: > > --db-- > faster than filesystem (according to some) > easier to separate from the webservers, since they only need one > datastorage that way > easier to tie to userid and such > damn big databasedumps > > --filesystem-- > faster than db (according to some) > easily handles big files > extra complexity to tie users to filenames and directories outside > the db > > Do any of you guys have any experience with this, or for that matter > any instinctive reactions to the problem?I agree with the others that there isn''t a clear winner. I personally prefer the DB route, *unless* those files need access through other means, such as WebDAV, SFTP, SCP, etc. That said, I don''t think the complexity to tie users to filenames and directories outside the DB is a big issue if you handle it correctly, namely be putting ALL logic to do so where it belongs, in the MODEL. In fact, you''ll know for certain that you''ve done this properly if you can alter just the model and DB schema and SWITCH the storage method without altering any controller or view code. That is the power of OO and MVC programming! Objects mask the implementation details from the parts that don''t need to know. :-) -- -- Tom Mornini
I''ve been using the "file_column" plugin, and recommend it for storing images. It''s fast, and easy to setup. On 2/10/06, Tom Mornini <tmornini@infomania.com> wrote:> > On Feb 10, 2006, at 2:57 AM, Martin Kihlgren wrote: > > > Now we have to decide whether to put these files on the filesystem, or > > in the db as blobs. > > > > The pros and cons we have summed up so far is: > > > > --db-- > > faster than filesystem (according to some) > > easier to separate from the webservers, since they only need one > > datastorage that way > > easier to tie to userid and such > > damn big databasedumps > > > > --filesystem-- > > faster than db (according to some) > > easily handles big files > > extra complexity to tie users to filenames and directories outside > > the db > > > > Do any of you guys have any experience with this, or for that matter > > any instinctive reactions to the problem? > > I agree with the others that there isn''t a clear winner. > > I personally prefer the DB route, *unless* those files need access > through > other means, such as WebDAV, SFTP, SCP, etc. > > That said, I don''t think the complexity to tie users to filenames and > directories outside the DB is a big issue if you handle it correctly, > namely be putting ALL logic to do so where it belongs, in the MODEL. > > In fact, you''ll know for certain that you''ve done this properly if you > can alter just the model and DB schema and SWITCH the storage method > without altering any controller or view code. > > That is the power of OO and MVC programming! Objects mask the > implementation details from the parts that don''t need to know. :-) > > -- > -- Tom Mornini > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060210/2f2136f4/attachment.html