Mysql shared columns to reduce repetition

I am trying to understand the best way to structure relational database tables which have many shared columns, but also a few extra columns. Similar to this question on Laracasts

For example, lets say I have a user table with the following columns:

|---------|
|  User   |
|---------|
|Name     |
|Email    |
|Password |
|DoB      |
|Address  |
|Etc...   |
|---------|

If I had an Employee table, this would be a user and thus have all of the attributes in the User table, but may also have extra columns such as employee_id, Payroll_number, Department_id, Start_date, End_date, etc...

A Customer would also have all of the user attributes, but would also need a customer_id, and card_number, etc...

I have thought about a number of ways to do this:

1. My first thought was to to just duplicate the columns in each table, so that employee and customer has all of the attributes a user would have. However, I don't think this is a very good approach, as it means duplicating the fields for each table and may also cause some issues when trying to authenticate a user against multiple tables.

2. My second approach was to keep all users in one table, with an extra attribute named roles, which has a many to many relationship with a userTraits table which would act like a key => value (i.e. trait_id, trait_name, trait_value). However, I'm worried that there is no restrictions at the database level to prevent a user from having a trait which shouldn't belong to that type of user, (i.e. a customer being assigned a payroll_id)

3. My third approach was to just have all users in the same table, but add all of the fields to all of the users and make most of them null-able, however, this has the same issues as my second approach, and wouldn't be very efficient.

4. My fourth approach was to try and use Laravels polymorphic relations, but this seems to give me the opposite of what I'm trying to achieve. As far as my understanding of this goes, it seems like this is used when you are trying to have several versions of the same type of data, so giving the Laravel documentation's example, having a post like and comment like share a likes table, by giving an id, likeable_id and likeable_type. However, if these two types of likes had extra attributes, then this would not work.

Unfortunately I cannot seem to find a design pattern that solves this issue and was wondering which way would be best to go about it? In the actual PHP implementation, I simply have a base class of User, which has subclasses of Employee, Customer, allowing them to inherit all of the functionality of User, but I cannot seem to find a way of achieving this kind of relationship at the database level.

Any help would be greatly appreciated.