One concept we use around here that has proved pretty nice is the "Lookup Code" table. If you have a database that has a lot of references to items that effectively codes, or types, or the like, keep all of them in a single LookupCode table that bases things off of a CodeGroup and the Code itself.
We keep an additional flag for the active status of the code, as well as a few optional numeric columns that can be used if given lookup code needs to be sorted or calculated in any kind of fashion.
By doing this, you eliminate having tons of tiny little tables scattered around your schema. Now one of the downsides to this is that the primary key for the table is the code group and code itself, so there isn't a foreign key attached to the "master" table that is referencing a given code, but a little bit of enforcement in the application is easily to accommodate for this.