Instead of looking up in a table, you can do this:
If the digits are all numerical, each would take 4 bits. that means 4+4+4+4+4+4 = 24 bits per ID, or to simplify, an array of . (adjust the numbers as necessary if you need to include alphanumeric ids)
If you use a file a file on an 16MB or larger SD card, which shouldn’t be hard to find, you can calculate the location in the file to read the data from rather than walking and comparing data to the whole file. There is a lot of wasted space for the swipe cards you don’t own, but lookup is a math calculation (offset) away and relatively instant.
For example, for card S 040 156 789 you can find if it is a guest or resident swipe by checking the byte at  in the single data file. (or offset 15255255+67*255+89)
You can simplify the space a lot too (supposing the cards are sequential) by creating files for each major number , such as 15.txt with the contents of all the 15-xx-xx based cards. This way, instead of having 1x16mb file, you have 255 files 65K (essentially an array of ). When the card is swiped, you open the 15.dat file and seek to position  (or 67*255 + 89) to read the 1 byte of data to determine what to do.
I use a byte in the above examples, and essentially you have 8 bit-flags you could set in that one byte of data on the file. You could divide all the sizes by 8 if you use 1 bit instead of a whole byte, but you have to first calculate the byte offset and pull the bit out of that byte.
… Anyway, I wanted to present an alternative to trying to search through data …