I have a script that repopulates a large database and would generate id values from other tables when needed. 
Example would be recording order information when given customer names only. I would check to see if the customer exists in a CUSTOMER table. If so, SELECT query to get his ID and insert the new record. Else I would create a new CUSTOMER entry and get the Last_Insert_Id(). 
Since these values duplicate a lot and I don't always need to generate a new ID --  Would it be better for me to store the ID => CUSTOMER relationship as a dictionary that gets checked before reaching the database or should I make the script constantly requery the database? I'm thinking the first approach is the best approach since it reduces load on the database, but I'm concerned for how large the ID Dictionary would get and the impacts of that. 
The script is running on the same box as the database, so network delays are negligible.
"Is it more efficient"?
Well, a dictionary is storing the values in a hash table.  This should be quite efficient for looking up a value.
The major downside is maintaining the dictionary.  If you know the database is not going to be updated, then you can load it once and the in-application memory operations are probably going to be faster than anything you can do with a database.
However, if the data is changing, then you have a real challenge.  How do you keep the memory version aligned with the database version?  This can be very tricky.
My advice would be to keep the work in the database, using indexes for the dictionary key.  This should be fast enough for your application.  If you need to eke out further speed, then using a dictionary is one possibility -- but no doubt, one possibility out of many -- for improving the application performance.
Is it more efficient to store id values in dictionary or re-query database