Did you know Facebook store their assets in MySQL, because it's the fastest replicated super-reliable thing to put them in? https://secure.phabricator.com/book/phabflavor/article/soon_static_resources/ (near the end of 'Caches and Serving Content')
I am in favour of weakening the warning On 25 February 2018 at 19:22, Tom Forbes <t...@tomforb.es> wrote: > Hey Antonie, > > Personally I’m quite against changing that warning. I have only ever seen > one application where the use of an in-database file is appropriate and > they where using the FILESTREAM type in SQL Server > <https://docs.microsoft.com/en-us/sql/relational-databases/blob/filestream-sql-server> > which offers some pretty advanced semantics compared to other databases > (more akin to Django’s file storage than a BLOB column). > > I’ve seen a lot of beginners use BLOB/byte fields where it’s really not > needed and struggle with some insane performance issues due to it - > especially with Django fetching all columns in a model by default. Also the > link you gave (and thanks for linking, it’s an interesting read) is > obviously Postgres specific, the issues you might face doing this are very > vendor specific and non-portable - sqlite recommends against storing > anything larger than 100kb in a row > <https://www.sqlite.org/intern-v-extern-blob.html> for example. > > I feel like the warning should implicitly say “do not do this, really > don’t, but if you’re super super super sure you 100% need to then you’re > going to disregard this warning anyway”, which the current one does quite > well. To put it another way, if you’re at the point where you need to do > this you’re way past reading the warning in the Django docs, and we should > deter people who might make the wrong choice at the start. > > Tom > > > > On 25 February 2018 at 23:21:39, Antoine Pietri (antoine.piet...@gmail.com) > wrote: > > Hi! > > In the documentation, the BinaryField has a warning called “Abusing > BinaryField” that states: > > > Although you might think about storing files in the database, consider > that > > it is bad design in 99% of the cases. This field is not a replacement for > > proper static files handling. > > https://docs.djangoproject.com/en/2.0/ref/models/fields/#dja > ngo.db.models.BinaryField > > I agree with the intention of this warning: we don't want people to > start using their database for image uploads, large static files, or > thinking they can completely replace proper static file serving with a > databse. > > That said, I think this warning is a huge overstatement. I think the > moment you're wondering "maybe this would be a good usecase to store > it in my database", your case for storing files in database might not > be absurd at all. There are tradeoffs, that are documented here, for > instance: https://wiki.postgresql.org/wiki/BinaryFilesInDB . It's > definitely not as clear-cut as "don't do it". People should be aware > of the tradeoffs instead of just dismissing the possibility. > > Can I suggest replacing the warning by something like this?: > > > Although you might think about storing files in the database, consider > that > > it might be a bad design choice. This field is not a replacement for > proper > > static files handling. > > > > That said, there might be cases where you do want the guarantees that the > > database offers you for binary files. Be sure to be aware of the > > trade-offs[1] before you decide to do so. > > [1]: https://wiki.postgresql.org/wiki/BinaryFilesInDB > > As I'm not subscribed to this mailing-list, I would appreciate to be > CC'd to the responses :-) > > Cheers, > > -- > Antoine Pietri > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-developers/28cec919-ae57-4eed-960b- > d598a01c2711%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/28cec919-ae57-4eed-960b-d598a01c2711%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-developers/CAFNZOJP967XiTqQBURfPN6W3KCOBp > giMEyCXw7aXbCSgWbNuhg%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAFNZOJP967XiTqQBURfPN6W3KCOBpgiMEyCXw7aXbCSgWbNuhg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Adam -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM0iaKL42A2LO34g7-w%2BbjOr6QXMAfJ7sS069uT2u_N79g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
