Skip to main content
Question

Setting up Notes

  • October 2, 2020
  • 0 replies
  • 72 views

I previously set up a group of related Notes tables, and it seemed to work fine, but there were a few nuances that I didn't particularly like. So I am rebuilding it from the ground up and had a few questions.

FYI: Long read ahead.

The way I previously set it up is the following:
  • 3 Tables:
    • Notes
    • Note Types
    • Note Subjects
  • Relationships:
    • Note Types < Note Subjects
    • Note Types < Notes
    • Note Subjects < Notes
  •  Note Types table - field:
    • Type
      • Text - Multiple Choice
  • Note Subjects table - field:
    •  Subject
      • Text - Multiple Choice
In the Note Type form, I can select a single type from the dropdown, then in the embedded grid I can select a subject from the dropdown for each grid row. Having a dropdown in the embedded form allowed me to relate multiple subjects to a single Type without having to manually type them in for every line. Hence the use of the Text-Multiple Choice for the Subject.

In the Note Subject form, I can select one Note Type from the dropdown and one Note Subject from the dropdown.

A single Note Type can have multiple Subjects related to it, eg:
  • Job (Type)
    • General
    • Left Message
    • Paint Sample
    • Parts
    • Pictures
    • Quality Control
    • etc
    • etc

However, a single Note Subject can be used in many different Note Types, eg:
  • General (Subject)
    • Assignment
    • Client
    • Contact
    • General
    • Job
    • Location
    • etc
    • etc
Also, in the Notes table, the Subject field is conditional on the Type field, such that when I select a Type, it only allows me to pick from the related subjects for that type.

I have thought about a number of different ways to accomplish the desired outcome, being that I have a Note Type and Note Subject in the Notes form with the subject being conditional of the type, but to do it in a cleaner manner (aka Best Practice). I have been kind of focused on Best Practice as of late and would like to ensure I am following it, not only for user experience, but for future development purposes. Just because something works now, doesn't mean it will be simple to follow in the future if this is ever handed off to someone else. I want to avoid that and ensure it is simple to follow so that development can continue if needed.

I believe best practice would be the following, but not really sure:
My first thought is to have the Type in the Note Types table be a Text field and input all the different types. I would also have the Subject in the Note Subject be a Text field. However, if I understand things correctly, by doing that and because a Type can have multiple Subjects, and a Subject can be used by multiple Types, I would need to establish a Many-to-Many table for the Note Types and Note Subjects. I would then need to relate that M:M table to the Notes table and set the conditional parameters ..... 

Any thoughts/ideas on the above, would it work, is there a better way to go about doing this? Is the way I originally set it up perfectly acceptable (I guess that might be subjective)? Suggestions? Recommendations?

------------------------------
Andrew
andrew.fry25@gmail.com
------------------------------
This topic has been closed for replies.

Andrew -

You're correct in thinking to make the Type and Subject fields Text. Since these are their own tables, the use of a Text-Multiple Choice is redundant and will only cause more issues later. The structure of this setup doesn't need to be super complex, but you are right in thinking you will need a Many to Many table for the Types/Subjects. I would suggest a structure like this:

The arrows in the diagram represent the direction in which you will need to setup the Parent/Child structure, with the points indicating the Child table. For this to work well, you will want to setup the reference field for the Type Subjects table to be conditional on the reference field for the Types table. You can do this using the Conditional Values section in the field properties here:

Once you have the structure updated and the values set in the various tables, you should be good to go!


------------------------------
Blake Harrison - DataBlender.io
Quick Base Solution Provider
------------------------------