Is there a consistent DB table naming scheme re plurals?

Is there a consistent DB table naming scheme re plurals?

由Matt Gibson發表於
Number of replies: 6

I'm aware that this will sound petty, but I'm getting really irritated that I keep having to go backwards and forwards to the DB viewer to find out whether a table has an 's' on the end or not:

With 's':

  • role_assignments
  • registration_hubs
  • course_categories
  • files
  • groups

Without 's'

  • question
  • user
  • course
  • lesson_branch
  • quiz_feedback

Or even two 's's:

  • groups_members

Apart from many-many tables seeming to reliably have 's' on the end, I can't see any consistency.

It would make SQL a lot simpler to write (especially for forgetful people like me) if we had a consistent policy. Any thoughts/preferences?

評比平均分數： -
In reply to Matt Gibson

Re: Is there a consistent DB table naming scheme re plurals?

由Tim Hunt發表於
Core developers的相片 Documentation writers的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片

There is a consistent policy:

  • One-word table names are singluar (course, user)
  • Multi-word table names have the last word pluralised, the rest singular. course_modules, role_assignments, quiz_grades.

Unfortunately there are three types of exception to that:

  • Very old tables, that date from before the above policy was standardised (modules)
  • Places where people screwed up. (quiz_feedback is not that old, and I should have known better Hopefully the new code-review policies will eliminate new additions to this category.)
  • Places where the policy was broken for a good reason (file is a reserved word, and pluralising is probably the simplest way to avoid that; groups tables have a long and complex history, and at one point it was necessary to come up with new table names, so the singular group was replaced by groups).
評比平均分數： -
In reply to Tim Hunt

Re: Is there a consistent DB table naming scheme re plurals?

由james mergenthaler發表於

Reminds me what my father used to say, "son, there is no black and white, only shades of gray".  It's important to have guidelines and policies, to avoid choas, but - there are always exceptions to the rules, especially in a big open source product like moodle.

peace.

評比平均分數： -
In reply to james mergenthaler

Re: Is there a consistent DB table naming scheme re plurals?

由Tim Hunt發表於
Core developers的相片 Documentation writers的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片

It should also remind you of the classic line in relation to internet standard "be strict in what you emit, liberal in what you accept". That is, any code you write yourself should follow all the coding guidelines perfectly. However, when looking at old code, you should be tolerant of what you find.

評比平均分數：Useful (1)
In reply to Tim Hunt

Re: Is there a consistent DB table naming scheme re plurals?

由Ray Morris發表於

I see that MOST modules don't follow that policy.  Is there any way to more actively encourage a policy to be followed?  Maybe because the rule itself is not consistent (some tables are supposed singular, others plural), developers don't notice that it's supposed to be consistently inconsistent?

Of the multi-word tables, exactly HALF and with an "s".  There are 259 multi-word tables. 130 end with an s.  So currently, a multiword table is equally likely to be singular as to be plural.  Most single word tables are singular, so it would be more accurate to say "all tables are singular" than to say "multiword names are plural".

 

 

評比平均分數： -
In reply to Ray Morris

Re: Is there a consistent DB table naming scheme re plurals?

由Tim Hunt發表於
Core developers的相片 Documentation writers的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片

You should sort your results by the date the table was added to Moodle. Most of the anomalies will probably be earlier in the development history (although there have been mistakes recently).

Once we have a table name that breaks the coding guidelines, there are two options:

  1. Fix it be renaming the table, which risks causing all sorts of regressions.
  2. Just live with it.

Often, option 2. is chosen, and it is hard to argue with that.

That is no excuse for you not getting it right in new code. In fact, it is a strong argument for getting it right first time.

評比平均分數： -