database design basics - big table searches

I would like some advice on this particular scenario:

Suppose my database is concerned with companies and their people, spread across the US, divided between states and smaller areas. Say some 40,000 companies over perhaps 1000 areas.

With searches on:
1) peoples' names - from the entire country, listing their company,
2) company - from the entire country - together with their people,
3) company by area - a list of all companies in a selected area - together with their people.

(The company list won't change much)

Now I imagine the easiest way to do that would be to have one table for people (which could grow BIG over time) with an ID linked to a separate company table (with 40,000 entries). My questions are:

1) Is one table with 40,000 rows really searchable in mySQL (i.e. quickly)?

2) And if people search by state and area, then that would require a search on two string fields from those 40,000 rows. Would that be reasonable? Or should there be other tables for states and areas? I have no idea whether joins or whole table searches would be quicker in bigger tables. There seems to be conflicting views (or maybe I don't understand it )

I'd like to throw this in the ring and see what others' opinions are... Any advice would be appreciated.
Many thanks

yes, it is very much searchable. try searching the php forum here which has 114,718 number of posts.
... and searching one table is definitely faster than searching two.

Dude... ronin... doesn't this post look a little familiar?

duuuuh... i don't have any idea what you're talking about, man.

roninblade,

Thanks for your reply. You say searching 1 table is quicker, so that means, with the company table, rather than having separate tables for state and smaller areas within, with just integer IDs held in two columns in the company table, it's better to hold the actual state and area name strings in each row of the company table? Seems to fly against what I've learnt...Or not?

Ctb,

Sorry - above my head...

//LOL

Nothing... jpenn asked a very similar question not too long ago, but it occurred to me after I posted that, after awhile, he finally did get a response. I thought maybe he was playing a joke or something, but I guess not. My bad! (I know someone here hates that saying...)

Don't mind me... I've wrapped up my project for the night and I'm a bit bored

that's exactly what you should do. i just said it's faster to search in one table rather than in two.

Umm...cryptic...the proper way is not the fastest way...

Ok. Any idea where I can find jpenn's original question. Are you sure he started the thread? I can't find it on a search in the database section.

Thanks for your help guys

im not trying to being cryptic here. you should normalize your database as much as possible. well even if you search a single table containing 40000 rows related to a number of other tables, mysql can easily handle the load.

OK roninblade, thanks a lot for the info. As a beginner to this db game it's difficult to know exactly how much constitutes 'a lot' to a database. I mean, it's difficult to even visualize 40,000 of something...