Database design - "Separate Tables Vs One table" for Select Queries - mysql

Question

I have a MySQL table like following
Books Table
book-id category author author_place book_name book_price --------other 50 columns directly related to book-id
1 adventure tom USA skydiving 300
2 spiritual rom Germany what you are 500
3 adventure som India woo woo 700
4 education kom Italy boring 900
5 adventure lom Pak yo yo 90
.
.
4000 spiritual tom USA you are 10
As you can see there are around 4000 rows and around 55 columns, I am using this table mostly for select query, Maybe add or update new book after2-3 weeks
I have doubt about the category and author columns
now if I need to select the table by category and author, I can simply do
SELECT * from books Where author = 'tom'
Select * FROM books WHERE category='education'
It works fine, But according to standard database design I think I should separate the category and authors columns into separate tables (especially authors) and use their primary key as foreign key in the books table
Something like this
Books Table
book-id categ_id author_id book_name book_price --------other 50 columns directly related to book-id
1 1 1 skydiving 300
2 2 2 what you are 500
3 1 3 woo woo 700
4 3 4 boring 900
5 1 5 yo yo 90
.
.
4000 3 1 you are 10
Category Table
categ_id category_name
1 advernture
2 spiritual
3 education
. .
. .
30 something
Authors Table
author_id author country
1 tom USA
2 rom Germany
3 som India
4 kom Italy
5 lom Pak
But then I have to use join the tables each time I make a select query by authors or category, Which I think will be inefficient, Something like this
SELECT * FROM Books LEFT JOIN authors on authors.author_id = books.author_id WHERE books.author_id =1
SELECT * FROM Books LEFT JOIN categories on categories.categ_id = books.categ_id_id WHERE books.categ_id =1
So should I separate the first table into separate tables or first table design is better in this case?

Answer 1

This question has it's answer from Mr. Edgar F. Codd himself - the inventor of the relation model upon which all RDBMS are build.
Shortly after releasing the relational model papers he and his team followed with papers on the so called normal forms. There are few of them but the first 3 (at least) should be generally considered mandatory:
First normal form (1NF)
Second normal form (2NF)
Third normal form (3NF)
When you read them you'll see that your initial design is in violation of 2NF and you have come with a solution that more or less respects it. Go ahead with a the NF-compliant design without any doubts.
To elaborate a bit on your concerns with Join's performance. This is not an issue as long as the following criteria is met:
your database schema is well designed (2NF compliant at least)
you use Foreign keys to link the tables (MySQL's docs)
you join the tables by their FK
you have the hardware resources necessary to run your data
efficiently
e.g. on MySQL with InnoDB, on 2NF compliant schema using Foreign keys the join performance by the FK will be among the last things you'd ever be concerned.
Historically there was a DB engine in MySQL - the MyISAM - that did not support foreign key constraints. Perhaps it's the main source of feedback about poor join performance (along poor schema designs of course).