AngularJS feels like Java, and likes camelCase.
HTML likes dashed-words.
MySQL docs like snake_case, but I see more PascalCase used in databases. It’s case-sensitive, too.
Parse.com uses PascalCase for tables/classes, and camelCase for columns/properties/fields. That’s like Java OOP.
Django likes to append _id to your primary keys.
So… the problems start to happen when one piece of named data is passed from one layer of the system to another. It’s just a good policy to use the same names at all layers, if possible.
The problem is, it’s not possible, for the following reasons:
Django’s habit of adding _id seems to have led to code that requires the database field to be named with _id. At the very least, avoiding this issue is difficult.
The field names are already being used in an app out in the field, and this database naming convention stuff didn’t get established until later.
Solutions
The general policy is to use whatever naming standard exists within a layer. The names should be converted, preferably automatically, as the data comes into the layer. For example, DRF field names conform to Python snake_case, but when they’re read by a JS program, the field names should be converted to camelCase.
If a name isn’t quite right, like it doesn’t conform to the naming standards you chose, fix it at the layer above it. Use the better, more correct name from that layer on up.
Specify all database column names explicitly. Don’t use Django’s. (Assume that you’ll be interacting with the database, directly, not only through Django’s models, and will want human-friendly names.)
Likewise, specify all table names explicitly.