What inheritance mapping strategy would you use here, if any?

Question

[Scenario]
I have a somewhat unusual problem. I have a set of entities, like Movie, Book etc. that all inherit Item class and that are perfectly identical in their structure (as none of them has any specific fields on it's own). They all have Id, Name, Description and Image fields, nothing else. The only difference between them is that some, obviously, represent movies, some of them books etc. If I didn't need to know their type, I wouldn't need inheritance at all.
[SINGLE_TABLE]
Obviously, all these entities could be easily persisted into the same table with a discriminator column (and entities themselves would have a @DiscriminatorValue) i.e using SINGLE_TABLE strategy. But, I would avoid this approach as there will be a lot of persisted entities, like, tens of thousands of each type (which means tables that map M-M relations could have millions or tens of millions of rows), so I'm guessing this approach would kill the performance.
[JOINED]
JOINED strategy has the same problems as SINGLE_TABLE.
[TABLE_PER_CLASS]
My opinion here, is that TABLE_PER_CLASS strategy would be the best approach, as I will rarely, if ever, query across multiple types. Item (the supertype) has only unidirectional 1:M relations, so , if I get this right, this is OK as well, as it avoids UNION when queried (please confirm or correct me on this), e.g. the query to fetch books and their votes (1:M) would resolve to SELECT * FROM Book b JOIN Vote v ON b.id = v.item_id, so no UNION... right?
But maybe I don't need inheritance mapping at all then...
What is your opinion here? Any shared thoughts are appreciated.

Answer 1

The disadvantage of using table_per_class would be that you have to duplicate the field structure many times (e.g. code duplication). If you ever want to change certain fields you (or the db-administrator) would have to do that a few times. Since in eventually you always have to use direct sql one time or another, making the database design as clear as the java code (where you wouldn't want code duplication either). Direct SQL you'd often need for optimilazition or because certain operations can be done in one SQL query, while requiring a lot of code if done in java.
You could use a single table, without losing performance. If you add an index to the discriminator type, a modern database will optimize queries and won't to full table scan. That way you have a clean database design, without losing performance.
If you ever need extra fields for say movie that you don't need for book (like duration in minutes, director), you can then create an extra table movie that contains only the fields that are extra. Retrieving movie then requires a join of item and movie, but since movie would be a smaller table and the join will be on indexed field, that wouldn't hurt performance.The database design keeps being clear and readable, as well as your java code.
If you really don't care about your relational database design, don't use a relation database but rather an object database. Object database are optimized for retrieving object graphs (retrieving a graph of objects won't require joins and table scans). The only disadvantage, aggragation of data is usually slower.