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...
Forum Discussion
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
------------------------------
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
------------------------------
