CODEWITHSUNDEEP
mysqldatabase
user9050678
user9050678

Reputation: 323

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

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?

Upvotes: 1

Views: 3522

Answers (1)

Alexander Marinov
Alexander Marinov

Reputation: 181

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:

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).

Upvotes: 5

Related Questions