How does a mapper turn class and property names into table and column names, and when must you override that?

When mapping metadata does not state a table or column name, something still has to produce one. That something is a **naming strategy**: a deterministic function from the names in the model to the identifiers in the database. It is the least visible part of a mapping and one of the most consequential, because it decides every identifier that nobody wrote down. ## What a strategy typically does - **Case conversion.** Model code and database schemas rarely share a casing convention, so a strategy usually rewrites mixed-case member names into the schema's house style. - **Word separation.** A multi-word name is split at its word boundaries and rejoined with the separator the schema uses. - **Table name shape.** Some layers use the class name as-is, others pluralise it; both are defensible and the choice is the strategy's, not the mapper's nature. - **Composed names.** Identifiers the model never named — the column holding a link, or the table standing between two collections — are composed from the names of the participants by the same rule. - **Length limits.** Databases cap identifier length. A composed name can exceed the cap and be truncated, and two different composed names can truncate to the same identifier. ## Three scopes of override 1. **Replace the strategy.** The whole schema follows a different rule from the layer's default. Changing one function fixes every identifier at once, and the model stays free of per-element declarations. 2. **Declare one element explicitly.** A single legacy table, or a column whose natural name collides with a reserved word, gets a stated name while everything around it stays derived. 3. **Quote the identifier.** Some databases fold unquoted identifiers to a single case; quoting preserves the exact spelling but usually makes the name case-sensitive from then on, so every other reference must match it exactly. The order matters when you are diagnosing a wrong name: an explicit declaration beats the strategy, and the strategy only fills gaps. ## Choosing between a global change and a local one | Situation | Right scope | Why | |---|---|---| | Whole schema uses a different casing or separator | Replace the strategy | One change, no per-element noise, new classes conform automatically | | One legacy table nobody may rename | Explicit name on that class | Keeps the convention intact for everything else | | A handful of columns whose names are reserved words | Explicit or quoted names on those columns | The problem is per-identifier, not systemic | | Names that must match a schema exactly, including case | Quoting, applied consistently | Prevents case folding from silently changing the identifier | A frequent mistake is reaching for the global lever to fix one name. Changing the strategy to accommodate a single legacy table rewrites every other identifier in the model, which is a schema-wide change made for one row of the problem. ## Legacy schemas Mapping onto a schema you did not design is where naming stops being cosmetic. The schema will contain abbreviations, historical prefixes, columns whose names encode a system that no longer exists, and identifiers that were once truncated. Two workable approaches exist, and they can be mixed: write explicit names everywhere and treat the strategy as irrelevant, or write a strategy that encodes the legacy rule — the prefix, the abbreviation table — and declare only the genuine exceptions. The second is worth it once the exceptions are a minority of the whole. ## Why the default is a decision Because the strategy runs on everything, a property rename is also a column rename. In a system where the schema is generated from the model, that is a migration nobody wrote; in a system where the schema is authored by hand and the mapping is validated against it, that is a startup failure. Both outcomes are better than the third: a layer that quietly maps to a new column that does not exist, or maps two members onto one truncated identifier. This is why a validation step comparing the resolved mapping against the live schema is worth its cost — it turns naming drift into a loud, early error. ## What to say in an interview Name the strategy as a single function, give two of its transformations, then explain the three override scopes and the case in which each is correct. Mentioning identifier length truncation and case folding on quoted identifiers signals that you have mapped onto a schema you did not control.