When naming a model, should the name be as generic as possible-- even if that won't be the name displayed to users?

For example let's imagine a Django model for liking another user's posts.

Does it make sense to name the model 'Like' even if I plan on displaying it as Kudos, Endorsements, Ups, etc?

Does it make sense to make the name as generic as possible, even if the name won't be the one displayed to the user?

  • Do you prefer to document these naming mismatches? – JeffO Aug 16 '13 at 4:11

In my humble opinion, naming should be as specific as possible. Following the single responsibility principle, table/field names should describe exactly what they were created for. This can help a lot down the track.

Taking your example, I would name the model "Kudos" (if that's what you're going to call your likes) as you may, down the track have another field named "Like". It will also help your developers communicate internally about concepts. If, for example, you are told by management to "add 15 kudos to everyone's account", that directly maps to your database. There is no translation required.

The only exception to this rule is if you have not yet decided on the name that will be shown to the user (which may happen for any number of reasons), in which case, it would be best to use the "best guess" at the most specific name. You can always change it later (though, like all requirements changes, this gets more expensive down the track).

|improve this answer|||||

Table and field names should be descriptive of the domain entity that they capture. If the domain entity is a customer, you should call the table "Customers." Like classes in an object-oriented program, tables follow the Single Responsibility Principle: each table should store instances of one thing (with all of its attributes), and one thing only.

To see why this is so, imagine the complete opposite. Imagine a system so generic that it's all stored in just three tables:

TableID     Primary Key
Name        Text

FieldID     Primary Key
TableID     Foreign Key
Name        Text
Type        Enum  (Text, Number, etc.)

ValueID     Primary Key
FieldID     Foreign Key
Value       Text

Notice that there's no identifying information at all in the tables themselves. You have to run a query to find the table you want. Then, you have to run another query to get the field that you want, and a third to get the field value.

If this looks familiar, it should: the first two tables are basically the "system" tables in an ordinary DBMS, which we have now re-invented. In fact, we have reinvented the entire DBMS. If you doubt this could ever happen, read here:


|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.