I am not sure I understand about the "size and synchronization" but I assume that is to do with them not giving you adequate infrastructure.
I don't think the DB advice is in any way specific to Django - I'd make the same recommendation regardless of the framework being adopted - but obviously there are sometimes constraints that force our hand to do things in non-optimal ways. You have my sympathies (for what they are worth). On Monday, 4 March 2019 16:30:04 UTC+2, Dan Davis wrote: > > Derek, it all depends on where you are. I'm \at a government agency. The > wait time to get an NFS directory (yup, really) where I can write my data > between multiple redundant web servers is weeks. After that, there are > size and synchronization issues. So, there are other reasons than table > design to consider. After all, we don't do the work to put our tables in > 1NF, 2NF, 3NF just because - we do it if our data is going to be used for > OLAP, but prefer less normalized structures for OLTP. > > I just think it is interesting that the standard advice about files in the > database has to do with Django's standard operations, and maybe ignores the > realities on the ground for some developers. > > On Mon, Mar 4, 2019 at 2:11 AM Derek <game...@gmail.com <javascript:>> > wrote: > >> Just because something can be done, does not mean it should be done. >> >> I have always avoided putting large binary files into the DB - why? >> Primarily because the information in them is "dead" - very hard to search >> or filter, which rather defeats the point of using a DB. Rather leave them >> on disc and add a pointer to each of them. For one app, I did convert all >> the data in their files (typically Excel or PDF) into "raw text" and stored >> that text in the DB so it was, at least, searchable (but obviously not >> really viewable in that state). >> >> Also, a call like: >> >> ModelWithFileContents.objects.all() >> >> Can be quite overwhelming unless you know what you are doing; rather look >> to extract specific fields that you know you want to display/access. I >> would imagine that the only time you are going to want to retrieve that >> BLOB (assuming you stick to your current design) is per individual record >> "on request". >> >> >> On Wednesday, 27 February 2019 03:18:00 UTC+2, Dan Davis wrote: >>> >>> For the group, the eventual culprit was not complicated. It is a model >>> with a BinaryField that holds a file's contents. The Django documentation >>> advises against this, but why? Well, on-premise with big-iron database >>> like Oracle, storing the file in the database is attractive. So, what's >>> the problem? >>> >>> ModelWithFileContents.objects.all() >>> >>> There you go, even if you are not using the file, its contents will be >>> fetched into memory. >>> The solution if it must be at the Django level is to use defer() >>> properly, and add it to the ModelManager. >>> >>> What I did is to make sure the developer *always* used a database view >>> that doesn't have the binary field for most operations. >>> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Django users" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/django-users/TZ682yh2QfE/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> django-users...@googlegroups.com <javascript:>. >> To post to this group, send email to django...@googlegroups.com >> <javascript:>. >> Visit this group at https://groups.google.com/group/django-users. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-users/b4e09fb6-b426-455d-aa3c-7191da404fc1%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-users/b4e09fb6-b426-455d-aa3c-7191da404fc1%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 users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/875d3cc7-5b25-4a5a-a1a9-5248b0c21c59%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
