Different tables with identical fields
I think you want to go with your first option.  Here's why:

You should design your database with a primary goal of maintaining data integrity.  Subtle data corruptions can be harder to debug than source code logic errors.  This is because corrupted data may only cause a detectable problem when a series of conditions occur at runtime.  Often you can't repeat these reliably.

The best way to focus on data integrity is to create a properly structured database.  If your data is going to be edited at any time, then you're best to start with a design that's in Third Normal Form (3NF) at least.  In general, you should have a table for each distinct type of thing that you have data about.

Sometimes, you may have two or more different types of things with similar attributes (data items).  This puts you in the position of deciding where you make your trade off.  Combining the facts about your things into one table means fewer tables.  Fewer tables will mean less code as long as the different types of things are and continue to be similar.  If you need to start moving in the direction of each type of thing having its own distinct set of attributes, then your code will become more complex and hard to maintain, with lots of branching logic.

It's important to remember that two different tables having the same set of attributes might be coincidental to your system or it might be consequential to your system.  Database structure design is not optimized in the same way as code reuse.  Cramming logically distinct but structurally similar data into the same table is not a good practice.  If you have two or more semantically distinct tables with very similar or even identical structure and your programmer's spidey-senses are tingling too much, then satisfy your urge for code reuse by subclassing in your code, but leave your apples and oranges in their own tables, rather than cramming them into a "fruit" table.

In a case where your two (or more) types of things are different from one another, then having one table for each type of thing is probably an excellent place to start.  This will keep your logic simple and your data clean, which makes for a high quality system.