views:

33

answers:

1

I recently started work at a new shop that uses a table naming convention like the following:

  • Users
  • UserRoles
  • UserUserRoles
  • UserProfiles
  • UserProfileLanguages

The convention I've been using is:

  • Users
  • Roles
  • UserRoleMaps
  • Profiles
  • Languages

When my boss asked why I don't prefix my tables, I explained that a database diagram would explain all the relationships much better than any naming convention could. I'm I wrong to assume that?

I'm willing to admit that the first example is more complete (especially if you're only looking at the tables directly), but what's the preferred solution for ORM? For example, in LINQ I would access my user's language like so:

User.Profile.Language

whereas, the first example would be:

User.UserProfile.UserProfileLanguage

Sure, I could easily rename my tables in the LINQ designer to whatever I please, but that quickly becomes a hassle if the data schema keeps changing.

EDIT: Removed APP_ prefix in example because it's not relevant to this question.

A: 

I could easily rename my tables in the LINQ designer to whatever I please

David B
Thanks buddy :/
Derek Hunziker