As a general strategy, I try to keep numeric all fields I can.
If the data is always numeric, then casting it as a number would be appropriate. Number fields have sparser indexes than text fields, so it would search a little faster and take up a little less disk space. (Not enough to notice in most cases unless you're doing a heavy scripting operation.) Whether that's what you meant by "better", I really don't know.
Forcing integer-only entry to a number field can be done a couple of ways. You can either use Round ( ), Floor ( ), or Ceiling ( ) to substitute the closest value as the user enters it, or you can apply a validation that says Int ( Self ) = Self.
If these values need to be counted or summed or sorted-by-value, then numbers are preferable. If I need numbers that represent TEXT (for display or for clarification of value), then I probably would use a table of these values and have "lookup" and/or valuelist and/or calculation and/or ??? (so many needs!)
(and you could have other columns should you needs further descriptions, names, etc.)
It all depends on end-use, but even a small table may have advantages.
I would wish for array-type functions that may better serve this kind of need and there are Ideas in this forum.
Another possible field validation (under Manage Database > Options...) you can use is "Member of value list..." This works well when you have a reasonably short list of possible values.
FWIW, and not an answer to the OP which has already been well answered...
For today's function, all of the above will do. But...
I inherit a lot of Dbases and try to support them or "modernize them to meet current needs".
From that perspective, the numbering of things that could just as easily have been a text list (PGH, ARC, TOR instead of 1, 2, 3) makes me cringe a bit.
The hardest part of looking at someone else's work is when they've made up their own language and number codes for things that they could have left clear to all.
My value list for "Yes", "No", Maybe", "Unknown", N/A" is not 1,2,3,4,5...it is Yes,No,Maybe,Unknown,N/A.
No one has to try to figure out what they mean...they say what they mean.
Dbases aren't just for today...someone else, or even you, may have to understand them later...think of them (or you) while inventing your numerical language and as yourself how it could be simpler...
There are so many tools in FMP to allow you to use things other than numerical codes.
(That said, if you're gonna do math on them, numbers sure do help!)
Just a short Friday rant, hopefully giving something the person following you in your work will appreciate.
I agree with Eric T.
Numeric codes are great until you have to retrieve them from long term memory or decipher what someone else has done.
Because of that I build for the person that may have to work on the system after me because it may be me.
Thanks for the good feedback.
To make this database I imported from a csv file. I have the original data dictionary and going field by field to match the field type of the original file. Filemaker of course imported them as text. Just trying to improve things going forward. From all your posts I think I will change the those texts fields to numeric.