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 <[email protected] <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 >> [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <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 [email protected]. To post to this group, send email to [email protected]. 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.
