I am using ORM to automatically create tables from model classes. I am naming the classes and their fields in a way that is natural for the application. The ORM then uses those same names for the tables and columns, and automatically generates names of other objects like constraints and sequences which are completely abstracted by the ORM.
I am not declaring how the tables, columns, etc. should be named. I leave it to the ORM to decide. I see this as good sense from the application’s point of view.
The DBA for my team does not like this one bit. The DBA says that if column “B” in table “A” has a foreign key constraint to field “Y” in table “X”, that the name must be “A.X_Y” instead of “A.B”. The DBA says this is the “correct” way to name foreign keys and that the ORM is therefore naming them incorrectly. Both of the ORM engines I am familiar with allow class/field names to be explicitly mapped to table/column names, so I am aware it is possible to accommodate the DBA without changing the classes.
My question is, in practice, does doing this (explicitly mapping the names) necessarily introduce an extra entity(i.e. new configuration files/sections, new code) or coupling (i.e. imports, decorators, annotations) in the application that might not otherwise exist? ORM designs vary, so I would think it is possible that the answer is different for different engines.
If the answer to this is nearly universally yes, I would consider that a good argument that the DBA should yield to the ORM in the interest of productivity, on the logic that the database exists to serve the needs of the application, not the other way around. Commentary on this point is welcome also.
Please note, I am NOT asking for specific recommendations on how classes/fields/tables/columns should be named.
You are right here. Depending on the ORM, explicitly specifying the field->column mapping might (or might not) introduce extra entities in the form of configuration entries, annotations, attributes etc. Having said that, this is the bread and butter (or should I say the very basics) for an ORM engine and hence handling these mappings usually does not add a noticeable overhead.
I feel you definitely cannot use this as an argument against explicitly naming the tables,columns etc. Most often than not you would have another application that would use the same database. The default names generated by your application might make absolutely no sense for that application. I would let the DBA decide the right nomenclature for the database artifacts and tweak the mapping to my domain model, in my app. After all that’s where the ORM adds value.