Question

I’m just wondering from design, efficiency and space perspectives, what’s a better choice? Self-join or using two tables and then joining them?

I have a MySQL database that stores product design details, the designer_type could be either company_staff, or a certain customer_type.

Initially I thought of having 2 tables, one called staff_design and one called customer_design.

Either way the design information remains almost the same, except that if it’s a customer, there are two extra columns that the staff_design doesn’t need, one which is a foreign key to the ID of a staff_design, and one which is design_name (something that users and not staff can add). Both of these 2 columns may be NULL.

So if I design the database such that these two tables are merged and there is only one design table, then this table will have 3 additional columns that might be NULL quite often: it’ll need to have design_type (specifying customer, or staff), and then the two extra columns I mentioned above. (design_name and staff_design FK).

Which design is better?

I’m leaning towards the single table design mainly to reduce hard disk processing (fetching two different tables rather than one). I’ll then have to use plenty of self joins.

What is considered professionally a better approach? There are expected to be thousands of designs saved by staff_designers, while only advanced and customers with an additional fee will be saving customized designs of their own. So there are certainly going to be many, many more staff designs than customer designs.

Answer 1

Since the order of magnitude of the records is only several thousands, I suggest to go for single table design. That will make your life easier and the size of the table does not justify the optimization of splitting the table.