Should you split a table that has a lot of columns into a few tables?

I have a users table for my company's management system. Right now, the previous developer split everything into separate table.

So you would have:

-
'users' ( id, email, username, password, first_name, last_name, last_login, etc ) for work related details

-
'users_info' ( id, user_id, personal_email, address, identification_num, education, etc ) for personal details

-
'users_files' ( id, user_id, photo, resume, offer_letter, etc ) for any attachments during hiring / registration process

There are lots more users related table ( the total is around 12 ). Now all of these tables has one-to-one relationship so you could just combine all of it into one big 'users' table with lots of columns.

We are currently in the process of migrating the whole app & restructuring the db itself ( normalization, remove redundant column, etc ). So my question is, which one is better in terms of best practice, performance, scalability & maintenance ?

It seems obvious that these all are parts of one logical entity type and so should be modelled together.

When it comes to implementation there may be good reasons for breaking a logical entity into several physical tables. It may be storage or performance optimisation, to give stronger security boundaries, to satisfy requirements that no longer apply, or even, sadly, politics. You may never know.

For my two cents I'd always start with a single table until I found a compelling reason to split it. If you find such a reason be sure to write it down for your successor!

StackExchange Database Administrators Q#319430, answer score: 2