If an application needs 100 different types of data object, then it needs 100 different types of data object. If you decide to write hand-written JDBC code or use a Hibernate implementation, the application still needs 100 different types of data objects. You cannot effectively use the total number of data objects as a realistic metric to determine whether to use an ORM framework or write the data access code from scratch.
The key here is to clearly identify what the requirements of the application are. Speculating or guessing that you will need to actually create 100 tables and also need 100 different types of data object is not productive analysis. The idea that you would need a
Java class for every data table in a database is a bit fuzzy and misleading. Aside, Hiberate mappings can be designed to extract from many tables in order to create a single persistent object.
Data requirements should be based on clearly written application requirements and design. If you are attempting to build an application and are starting to design a relational database first, you most likely will end up with a weak application design.
Keep in mind that Hibernate is a powerful, ultra-high performance framework. It is highly unlikely that you can write more efficient code than the Hibernate programmers. This is one of the primary reasons why using Hibernate is a best practice.