Do i need 2 tables to book entity?

Question

I am developing a website to store books info such (title, book_no, author, edition, container...). I have two types of insert

1. insert series of books (Eg: harry porter series: chapter 1, 2,3...)
2. insert single book

I have created two table for this series and books, series table to store series info such (series_title, author, edition...) and books table to store books info such (book_title, book_no, container). To insert either series of books or single book I have two forms to submit, one is inserting series info 2nd is inserting book info for that particular series. This way makes my app easy like no need to enter series info multiple time when inserting each series of book, I can easily check books under particular series, I can easily search books.

Now I have a situation that, also I have to insert the books from excel sheet which is got 1000s book info. But the problem is it has included single book and series of books, so i cant differentiate either a single book or series of book. for this, if I merge my tables into only books table I can archive this but i have to lose some of the features that I told before. am I doing this wrong? please explain to me if there is an efficient way for this

Answer 1

I think your separate table for series is a good solution. I assume you still put each book in the book table and link them to a series row?

The problem with any solution you come up with is that you cant force everyone else in the world to follow it.

If you got rid of the series table you might find the next import did have a separate series tab.

I would imagine that you could add some initial parsing to the excel spreadsheet to try and determine when a book was in a series.

Perhaps you could lookup the author on wikipedia and parse the webpage? I've noticed that they often have well formatted lists of series and books. It wouldn't be 100% accurate, so you would need some human checking after each upload.

Answer 2

The series table should enumerate what individual books are in each series.

However, it seems reasonable to me to have the series itself also listed in the books table (add a column indicating series or not).  This way, you can search just the books table and find series as well (or exclude them by qualifying the is-series column).

This would be like an employee table, where some employees are also managers and thus have subordinates, so that a search employess can easily search either non-manager employees or manager employees or across both.

(Also, just as a manager's subordinates can also be other managers, you can support a book series (or some higher level composition) that might itself contain series or sub-series.  (fyi, if this an ordinary kind of hierarchy, then we could work with a parent column instead of a second table.))

Considering a series to be in the "book" table: the import sources that are lacking series-differentiating information are not so much dead-wrong (or in conflict with such table design) as merely incomplete.  And you can devise methods for augmenting the additional information (as @Ewan suggests) — perhaps even detecting potential series, such as observing that multiple books of same author having title similarities in or after some import.

If you don't know about series information, at worst you'll have a series in the books table that is not necessarily marked as a series (and missing information in the series table), but the general schema will support the notion of series, and is easily corrected if you learn of a series that wasn't entered at all (perhaps just the individual books are known) or that some "book" turns out to be a series.

You might make the "is-series" column a tri-value that indicates (yes, no, and unknown) to use if this book was imported only from a source that doesn't offer series vs. book differentiation.  (Or, if you want to go nuts, capture the full provenance of source(s) of information on this book.)

Answer 3

Yes you should make 2 tables for book entities. As you have different types of records to be inserted in the table. In one table you only have books which have series or multiple editions while other table has those books which have only single edition. It will become quite easy at the time of fetching the data.