Simple design make great application!
I've got a similar design within the app I'm working on, with > 260 lookups for > 4000 values.
In addition to the fields you've mentionned in your design, I've got as well the following fields:
- an internal description, something which is never displayed to the end user but provides insider information for developers to what really is the value about, some info you may not want your end-user to see
- who has created and updated each record, as well the associated timestamp, which helps tracking changes in the application
- for lookup values, there's both a string value and an int value, where it's up to the code to decide to use one or both values
Even if this makes a much slicker DB design, there are 2 problems with this that I've accepted to live with:
 when you read a query, joins are not really explicit, if you're not properly specifying your aliases... to cope with that, I've got a script that automatically creates a view for each lookup type, with a meaningful name and restricts th e values to the lookup type you want; if these views are used in the queries, it makes them much easier to read, but there's some maintenance and the view overhead
 referential integrity... ok you can have a FK which will ensure that your main tables are linking to a valid value in your lookup table, but there's nothing that prevents assigning a value to a field outside of its type - say, if you've got a 'countries' and 'job types' lookups, you've got to ensure programmatically that you're not assigning a job type to a country field and vice-versa.