For storing people in MySQL (or any DB) - multiple tables or just one?

One 'person' table is the most flexible, efficient, and trouble-free approach.

It will be easy for you to do limited searches - find all people with this last name and who are customers, for example. But you may also find you have to look up someone when you don't know what they are - that will be easiest when you have one 'person' table.

However, you must consider the possibility that one person is multiple things to you - a customer because the bought something and a contractor because you hired them for a job. It would be better, therefore, to have a 'join' table that gives you a many to many relationship.

create person_type (   person_id int unsigned,   person_type_id int unsigned,   date_started datetime,   date_ended datetime,   [ ... ])

(You'll want to add indexes and foreign keys, of course. person_id is a FK to 'person' table; 'person_type_id' is a FK to your reference table for all possible person types. I've added two date fields so you can establish when someone was what to you.)

Since you have many different "types" of Persons, in order to have normalized design, with proper Foreign Key constraints, it's better to use the supertype/subtype pattern. One Person table (with the common to all attributes) and many subtype tables (Employee, Contractor, Customer, etc.), all in 1:1 relationship with the main Person table, and with necessary details for every type of Person.

Check this answer by @Branko for an example: Many-to-Many but sourced from multiple tables

250.000 records for a database is not very much. If you set your indexes appropriately you will never find any problems with that.

You should probably set a type for a user. Those types should be in a different table, so you can see what the type means (make it an TINYINT or similar). If you need additional fields per user type, you could indeed create a different table for that.

This approach sounds really good to me