MySQL database design, two types of records - use one table or two separate tables?

I'm building an application that will have two different types of users, lets call one User_type_a and the other User_type_b. I'm wondering if I should create 1 table in my database for both types of users and have a property distinguishing what type of user each record is, or if I should create two separate tables for each type of开发者_如何学JAVA user.

Considerations: 1. 99% of all users will be User_type_a 2. User_type_b will require properties in addition to User_type_a (such as credit card #'s, etc)

Which design approach is optimal? Or does it not really matter.

One table for users, assuming that user type b are real users. Create another table that links to the user table to store the CC details for user type B.

This allows you do do all major user changes easily (searching users, changing user details, looking up users for login, etc), but doesn't contain many wasted columns.

Note that if you are storing credit card numbers, your datacenter and architecture will have to be PCI compliant, which is expensive.

If type B has only additional information (columns) to the generic user type then use:

If types A and B have some common columns and a set of distinct columns for each one, then use

I both cases keep all common columns in the User table -- sub-type tables have only columns specific to each one. Note that UserID propagates to sub-type tables.

The best way to do this would be to store all users in the same table, and have a foreign key relating to a second table, which contains the extra information.

**USER TABLE**
NAME     AGE       TYPE     FK
Grant    25        Adult    1
Susan    4         Child    null
John     65        Adult    2

**EXTRA TABLE**
FK    CREDITCARD    OTHER
1     234234...     blah
2     2334...       blah

This would be more efficient with space.

So it sounds like User_type_a and User_type_b are both identical in terms of data, with the exception being that User_type_b has additional data above and beyond User_type_a (but User_type_a does not have any unique data like this).

Given this, I would create a single users table that stores the User_type_a data (i.e. the intersection of the two user types). Then create a second table for the additional User_type_b data, with a foreign key linking that one back to users. (Note that there is no column here in the users table defining which users are which type.)

How to tell the difference between the two user types? Simple: User_type_b has a related row in the second table; User_type_a does not. This makes it easy for any application functions that don't care about the difference to just get the common user data for everyone, while functions that need the extra User_type_b data (or otherwise only care about one type or the other) can still determine who is what type and get that extra data.

Use one table. They are both users. Your code will have more general use between both types so you will avoid having to do 2 sql queries when dealing with users (even though they are not relevant 99% of the time)