One note, somewhat unrelated it's not an object hash, but rather a BSON ObjectID which is somewhat more predictable than a hash. It's a small point, but it can be an important one.
There are a couple of things which will usually swing you one way or another:
- Are they all guaranteed to be base 10 numbers? If so, then you should be save storing them as such, and it will usually be more efficient to do so in terms of things like index size (and usually object size and storage, but that depends on the string).
- If there are hex digits or similar in there, or if there is any doubt about the content, then you will want to go with a string instead
If you do go with a string type, be aware of the slight quirks involved with Lexicagraphical ordering which will be used for any sorting and to satisfy range based queries on the field. Again, these are not usually show stopping problems, but they can cause some interesting results if you are not aware.
Finally, make sure you pick a type and stick to it if this field is going to be indexed. You are allowed to mix types in a field in MongoDB - having a flexible schema is one of its major strengths, but if you index such a mixed field you will only generally get results for the type you query on. For example, querying an indexed field using an numeric type when it contains a mix of strings and numbers will only yield results from the number type and vice versa.