On 3/27/07, Marc Fargas Esteve <[EMAIL PROTECTED]> wrote: > Hi, > If you provide a BinaryField it's just a matter of time that "hacks" will > start to go out on blogs, the wiki or even django-users to get ImageField > and FileField on the database (there's a hack on this already), maybe it's > 99% bad but if those fields are provided inside django it will be much > better than having lots of hackish ways around. > > And anyway, there's still a 1% of cases on which it's good design, normally > cases of big applications.
For big applications it's especially important not to have their DB serving static files. One of the first optimization advice that comes with Django is: use separate web server for serving static files and use separate box for your DB this would be like doing exact opposite - put the load of serving static files onto the already busy DB server > > An argument for supporting Image/Field on DB: > Consider a case of multiple frontends with a big big database, having > File and Image fields on filesystem forces you to keep the filesystem in > sync among frontends. Now imagine you upload a file which is i.e. the image > for an article; The article is inserted on the database and the file on the > filesystem. All frontends will **immediatelly** show up the article, but > only one will have the image! unless you start playing around with NFS or > other networked filesystems. network filesystem or NAS is the 'right solution' here, even if NFS is not the best solution performance-wise (NFS is slow) its still WAY faster than DB and can be on a separate box. again, this is important especially for large projects, that need their DB server to be unburdened by static junk > It can also be a bit messy to do Point In Time recoveries, with everything > on the database you can to a nice PTR without any trouble, if there are > things on the filesystem you must make sure both things get recovered to the > same point in time, and it's rare to see filesystems backed up > **permanently** while point in time recoveries in databases (atleast > postgresql) are heavily documented and a good resource for some kind of > applications. OK, goo point here, but its very minor issue, basically only media rich servers will use this and they would completely kill their DB server with the traffic (if it's that high that ''rsync'' cannot be used every 2 minutes) > Third case; Imagine having one single directory holding a project but you > run multiple instances of it over different databases (yes, doing tricky > things to settings), having things on the filesystem makes things a bit > harder. just put the DIR in the settings as well, I see no point here > > I'm +1 on providing database backed File and Image fields while heavily > discouraging it's use on the documentation by providing clear examples of > the 99% and 1% sides of the thing so users are aware of which storage method > should they choose. > > Also +1 on the BinaryField, then atleast if one **really** needs to store > things on DB it could be done :) even though you raised some good arguments, I still believe BLOB's are mostly evil, and will be misused. that said, I am -0 on this. its inviting people to shoot themselves in the foot. I would be +1 on a BIG RED SIGN saying not to use it unless you REALLY KNOW what you are doing... ;) > > Cheers, > Marc > > > On 3/26/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > > > On 3/26/07, Simon G. <[EMAIL PROTECTED]> wrote: > > > So - if we do want a BinaryField we could use #2417 and make it > > > suitable for larger binary stores (e.g. the VARBINARY used for MySQL > > > has a max length of 255 bytes - perfect for the small bin. chunks > > > wanted in #2417, but not for larger data), and then hook it up to > > > Image/FileFields for #652. > > > > > > An alternate solution is to check in #2417 for small binary chunks, > > > and then hold 652 back until we decide if we want a LargeBinaryField > > > for large binary chunks suitable for file uploads. > > > > +1 on having a BinaryField. I'd actually like to see BinaryField be > > the "larger" binary field, and have a SmallBinaryField alongside for > > databases with those types. > > > > -1 on allowing File/ImageField to be stored in the database. That's > > bad design 99% of the time, and will needlessly complicate file upload > > code. > > > > Jacob > > > > > > > > > -- Honza Kr�l E-Mail: [EMAIL PROTECTED] ICQ#: 107471613 Phone: +420 606 678585 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
