4 ms·

I relate with the author about what a Django's database could become if not handled with care. In my experience if one creates models using a lot of inheritance

I relate with the author about what a Django's database could become if not handled with care. In my experience if one creates models using a lot of inheritance then the database becomes a dumpster and it's basically impossible to get any data out of it with something different than Python itself. The only sane way is to think about tables first, create models that mimic those tables, use makemigrations + migrate and absolutely no inheritance in the models. An extra bonus is only one app per project. I've got a customer with two projects: one with many apps and a lot of inheritance, the other one with one big app and a few very small ones and no inheritance. We can use any SQL tool to extract data from the database of the second project. The database of the first one is "spaghetti data" and "python3 manage.py shell" is the only way to make sense of it. On the other side we could say that at last a djangified database is a truly object oriented database.

jmconfuzeus 5y ago
You'd be surprised how many developers are working on Django projects right now who have never written a line of SQL in their entire lives. Instead of thinking about data and business logic, they're preoccupied by code and separation of concerns. That's why we end up with database that are unqueryable from outside of Django's ORM itself. Good luck if you end up working in a project that makes heavy use of GenericForeignKeys.
Nextgrid 5y ago
Model inheritance is indeed hell. Doesn't necessarily mean it should be removed (it might be a good shortcut and might be fine depending on your performance requirements) but it should be handled with care for sure. Same with generic foreign keys. I don't necessarily agree with your objections around how Django apps structure their database though. The need to access said database outside of Django should be a business requirement that's considered and if needed taken into account when designing the models. For projects that don't have said requirement it's not a problem because nothing meaningful should be accessing the DB (and if it does, then the application should be changed). It's kind of complaining that some third-party application's internal data file format doesn't suit your needs - well yes obviously it as it was never designed with you in mind in the first place.

jmconfuzeus 5y ago

You'd be surprised how many developers are working on Django projects right now who have never written a line of SQL in their entire lives. Instead of thinking about data and business logic, they're preoccupied by code and separation of concerns. That's why we end up with database that are unqueryable from outside of Django's ORM itself. Good luck if you end up working in a project that makes heavy use of GenericForeignKeys.

Nextgrid 5y ago

Model inheritance is indeed hell. Doesn't necessarily mean it should be removed (it might be a good shortcut and might be fine depending on your performance requirements) but it should be handled with care for sure. Same with generic foreign keys. I don't necessarily agree with your objections around how Django apps structure their database though. The need to access said database outside of Django should be a business requirement that's considered and if needed taken into account when designing the models. For projects that don't have said requirement it's not a problem because nothing meaningful should be accessing the DB (and if it does, then the application should be changed). It's kind of complaining that some third-party application's internal data file format doesn't suit your needs - well yes obviously it as it was never designed with you in mind in the first place.