Provide finer control over table name conventions

[ejm]

This is a suggestion about database table names and the way they are generated or specified. I think it would be useful if there was finer control over this.

The current default behavior (<app_name>_<model_name>) is good, but it would be useful if we could, for example:

• specify an optional root "label", so that tables are named <root_label>_<app_name>_<model_name>
• specify a different label for the <app_name> part (e.g. a generic 'db_table_prefix' setting that is somehow set app-wide, and which defaults to the app name)
• specify whether to pluralize the <model_name> (possibly using the model's 'verbose_name_plural' property, or a new property e.g. 'model_name_plural')

There are probably more properties that could be added to control different aspects of name generation.

Also, if such mechanisms were provided, then possibly some of the django.contrib packages (e.g. sites, sessions, contenttypes) could use them to provide better names for their tables, rather than hard-coded 'django_sites', etc.

The reasons to be flexible and provide finer control over table naming conventions:

• To allow Django to work alongside another platform, under a common naming scheme
• To make the database schema more understandable to human viewers (i.e. code readability considerations, maintainability, future-proofing)
• To keep the database conceptually separate from Django - to not have 'django_' prefixed tables or magical, "internal-looking" tables, like some other frameworks (Django is already pretty good about this and I think it fits with what I understand of the project philosophy)

[Russell Keith-Magee]

I'm going to mark this wontfix. If you are adopting a framework, at some point you have to accept that a framework has some conventions, especially over something as fundamental as table naming.

The idea that is being proposed would add complexity to the code, but ultimately would only improve the life of a very small number of db-admins that don't like their naming schemes being messed up by a framework.

I don't pay the 'more understandable' argument. Reliable and consistent naming of internal tables is a usability issue in itself - if you bring a contractor into to work on a project, it helps if that contractor automatically knows what the content types table is called. Consistent naming can run deeper than a single code base.

I also don't pay the "conceptually separate" argument. At the end of the day, tables like content_types *are* internal. While we certainly don't prohibit anyone from tweaking them, I wouldn't describe that as generally good practice.