• 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

18 Comments

  1. Anonymous

    Any suggestions for Join Tables?

    JoinPeopleClasses seems clumsy and could get long? JPeopleClasses only marginally better.

    Tim Anderson

  2. Anonymous

    Similar question here. I am working on a project and I have a Phases table and a Features table. I need a PhaseFeatures table to break the many-to-many relationship, and as much as I've thought about it, I can't seem to be able to find a single word to name it. Shouldn't you add anything to the standard to cover those cases?

    Carlos Sierra

  3. Anonymous

    Matt, hook up a Join Table convention please.

    Thanks

    1. Matt Petrowsky

      Ok, here is my first suggestion for a join table indicator. Since our spec here defines that the last word in a TO is the Basetablename, the first word should be descriptive of the functional application.

      Since we're looking to clarify what this table is (in relation to the tables it is connected to) I'd say we just add the other double chevron.

      Within code, this would quickly identify the TO type as a join. Here's an example...

      Tables = People, Rooms, Seats, Classes

      Where People, Rooms and Seats are physical manifestations and Classes is an abstraction based on a time based event. A join between People and Classes might look like this.

      Students » People
Students «» Roster
Students » Classes

      You can see that Roster is a join table because of the «» indication. However, it shouldn't be confused that the » indicates a direction for the relationship. Because FileMaker's graph is bidirectional, we don't necessarily want to cause confusion.

      Essentially, all we really need to do is change the symbol used between FunctionalArea and Basetablename in order to indicate the uniqueness of the table type.

      Also note, I mentioned a Seats table above for the benefit of someone who is designing a Education type solution. Of course, the data design always depends on the needs of the solution. But the true nature of a class is to be limited based on the number of possible seats. This could be connected in many ways. The Seats could be hanging off the Class and logic would prevent new additions based a limited reached, or the relational connections could have a double join where it would look like this.

      Students » People
Students «» Roster
Students «» Seats
Students » Classes

      Where the Seats table has a pre-defined number of record rows for each class, which, in turn, defines the limit for a class.

      Also note that Students could easily read "Enrollment" which would be more identifiable as to the FunctionalArea of the solution. Follow this up with "StudentEnrollment" and it's even more defined when you might need to contrast against "FacultyEnrollment".

      So this should be pretty clear (at least in my mind) as to what this structure of TO's is doing.

      StudentEnrollment » People
StudentEnrollment «» Roster
StudentEnrollment «» Seats
StudentEnrollment » Classes

      Any other ideas?

      1. Perren Smith

        Matt,

        I like this idea, but for those of us who are still learning the keyboard shortcuts for cooler ASCII characters what is it for the left pointing chevron?

        --Perren

        1. Anonymous

          On a Mac, it's option-backslash for the left-pointing angle-quote («) and shift-option-pipe for the right-pointing one (»).

      2. Anonymous

        "Since our spec here defines that the last word in a TO is the Basetablename, the first word should be descriptive of the functional application."

        This info should be put on the 'Table occurence naming' page!  Not clear there.

        1. Matt Petrowsky

          We've not fully ratified the use of «» as a join indicator yet. Of course, it would help if we did have a process. (smile) If this convention seems like a good one then I can add it to the Table occurrence naming page.

  4. Anonymous

    I'm not sure your "bad" example is a good one. There are perfectly valid reasons to have a Students table.

    1. Matt Petrowsky

      I don't think you're reading "into" the purpose of the convention. It's not there to specifically say you shouldn't use that specific word - to be specific. It's there to provide insight in that any well designed solution will do everything it can to remove ambiguity. While I may always think of myself as a Student (always learning), as a Person, I may not always be classified as such.

      I believe the contrast serves to make a good point, because many newbie developers will start off creating a table named Students when that's the context they're thinking in. Later down the road, they want to create a Faculty table and now we're starting to make spaghetti (not the yummy kind). People are people, they are simply classified or labeled.

      Did you like how I tried to be really specific? (smile) (got carried away with specific uses of specific)

  5. Anonymous

    For anonymous:

    http://alt-codes.org/list/

    A list of alt codes for you.

    1. Anonymous

      Sorry that was for Perren

  6. Anonymous

    Would it be safe to say a Table name should always be a plural noun?  Might be easier to think about that way.

    (Unless it's full of Globals or something, 

    so it might not be plural in that case.)

      

    1. Jeremy Bante

      I actually use singular nouns whenever possible. Most database operations either act on single records, or do the same thing to each of several records. Off the top of my head, I'm having a hard time thinking of something I do on a regular basis as an example of doing something to a set of records from a table that can't be decomposed into doing the same thing to each record. Tables aren't the object of much of anything I do; records are. I don't really do anything with tables, so much as records within tables. So the singular noun format is easier for me to read. For example, if I'm referencing the nameFirst field from a related record in a table of people, "Person::nameFirst" makes more sense to me than "People::nameFirst". What's a "People"?

      1. Perren Smith

        I second this argument for the core Table names in Define Database. If it makes more sense in a particular situation for a plural variant of a Table name I'll typically do that via a Table Occurrence name where it's potentially exposed to the users. 

        There just doesn't seem to be a compelling reason to stray from singular nouns for core Tables - it's just about the last object name that will ever end up being seen by anyone except the developer(s).

        1. Matt Petrowsky

          I'm personally completely ambivalent about Person vs. People. For me, I think I tend to go plural because in my mind, my database is dealing with People as opposed to me thinking I'm always dealing with a Person at a record level.

          When I read the code

          Customers » People::id

          vs.

          Customers » Person::id

          I get the same meaning because People implies Person within a singular context (although I'll admit the later "feels" a bit better).

          While I wouldn't suggest we push singular over plural in the standards, I do think we might benefit from a suggestions list in Best Practices. What do you think?

  7. Anonymous

    Hi,

    I am interested in how you ened up with '»' as the join character. It seems a bit obscure.  I feel like I've missed a big chunk of the conversation.

    Cheers

    PJ 

    1. Matt Petrowsky

      The reason for using the » character is to give a very distinct visual indication (within code) that you're looking at a table occurrence.

      I have made a note on the Table occurrence naming page about a web variation which uses double underscores. The suggested best practice solution model is to create a dedicated web file that accesses a shared data file, thereby keeping the possibilities of messing up your client/server solution down to zero. You would be able to use the web compatible variation within the web dedicated file.

      However, I'm sure there are people (actually I know there are) who just can't come to grips with using what they perceive as such an odd selection - despite FileMaker being able to handle Unicode quite gracefully.

      We're always open to suggestions with the understanding that code readability is one of our primary objectives.