Forum Discussion

ZacCampbell's avatar
ZacCampbell
Qrew Member
4 years ago

Text-multiple choice field limits?

I'm debating whether or not a potential text-multiple choice field should just become a separate table. 
  • How many choices can you have in a Text-multiple choice field, is there a limit?
    • I see there is a limit to Multi-select Text fields when looking at the Help section. It notes these have a maximum of 100 choices but does not specify if this limit also exists for a text-multiple choice field type.
    • If there isn't a limit, then I believe I'm on the right track and would use this field type. 

The breakdown in question:

I have a table of Addresses. Subdivisions (possible field type) can have many addresses attributed to them. However, some addresses are not apart of a subdivision at all and thus would be labeled as a choice "N/A" if I were to make a massive list in a text-multiple choice field type for Subdivisions.

There are many Subdivisions in our service area, so again this list would be quite long, and I'm ok with that. I don't need any additional information on each subdivision besides its name, so I don't need a whole separate table. I don't want to have a long list, and then a year later, we run into a limit on said list, and I'm forced to rethink this part of our app. That would suck. 

Am I off with my thinking here? Go easy; I'm new.



------------------------------
Zac Campbell
Houston TX
Geaux Tigers!
------------------------------
Tables and fields

1 Reply

Sort By
  • SamJones1's avatar
    SamJones1
    Qrew Cadet
    4 years ago
    Hey Zac,
    You could totally go ahead and have just a massive text multiple choice field. That should work. 

    I would not do that, however. 
    Reason 1: Have any of the subdivisions ever changed names? If so, you'll want to preserve existing data about them while still updating the name. Having a related table allows you to do this. You can change the name on the subdivision record without changing the data it's tied to

    Reason 2: When you make it a table, you get to use the searchable record picker. If you're dealing with a large data set of subdivisions, it may be easier to just start typing text from the middle of the name. Consider if you have 30 sub divisions with names starting "Southern..." and you need to find "Southern Comfort Way" and don't want to scroll past "Southern Aarvark" every time.
    (Full disclosure, I helped build the searchable record picker, in part because of this particular use case.)

    Reason 3: Right now you don't have other information to track about Subdivisions. This may not always be the case, and it'd be worth having the table in place because at some point you'll find a use for it.

    Happy to chat more about this during Data Collaborative's free office hours, every Thursday at 1pm Eastern.
    Sign up here: https://data.quickbase.com/db/bqeqqj33i

    ------------------------------
    - Sam

    ______________________________________________
    Sam Jones
    Vice President, Product and Technology
    he/him

    The Data Collaborative, Inc.
    sjones@datacollaborative.com
    366 Massachusetts Ave, Suite 203 | Arlington, MA 02474
    ------------------------------