You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

  • Tables: are named using a single word in Title case and should not be represented by attributes of the data it contains. (e.g. "Employee" is an attribute of "People" and "Schedule" is a group of "Events").

    People

    good

    Students

    bad

General vs. Specificity

For clarification, the indication of Students above, as being 'bad' should not be misinterpreted as a bad choice for an actual table name - if a table named Students fits the requirements of your solution. The indication is there because the storage of an actual person who happens to be a Student at the time, should be within a general People table and identified via the data itself (e.g. using either another field as a tag or a join table structure to associate that person as being such a student). A student today is not always a student tomorrow, but they're always a person.

Notice how

Schedule » People::id

will be much easier to read within calculation code as opposed to

People__Class Students::tk_student_id
  • No labels