Search box/field design with multiple search locations
I could see this being posted to the UX SE (ux.stackexchange.com I think?) site, or they might already have a question there touching on something like this.  But personally I would probably lean toward either a dropdown selector with different types, or keeping the separate searches as-is.  And I think I'd lean more toward the dropdown box - that doesn't seem unreasonable to me for a search interface.
I guess one question would be - could there be any expectation to want results from more than one of the tables in the same search?  If that were the case I could see implementing your unified search idea even though it would mean querying multiple tables. Or some sort of additive interface where you select the tables you'd want to query.
Not sure if this question is better suited for a different StackExchange site but, here goes:
I have a search page that searches a number of different type of things. All (at the moment) requiring a different input field for each type of search. For example, one might search for a school or district name, a class name, a staff member email address, etc. I have 9 different 'type' of searches each with their own input field on the search page. I've already concatenated one of these (a username and UID search) but I'm wondering if it makes sense both design (user friendly) and performance wise to bring these all into one input field (and therefore one singular search)
These different types are of course a number of different tables, so it would have to query a number of different times for each type, just for one search.
Any ideas? or should I just keep it how it is? I could add a drop-down menu to choose a different 'type' of search but that seems just as messy. I'm already doing this for my navbar when not on the main search page (which also happens to be the home page) 
My project is written in Python with the Pyramid framework.