I would look to using an ORM. Essentially you could create your entities and models from your database schema. This first step is fairly easy to do with most ORM's. I have done this many times with Hibernate. Focus on keeping things simple. Do not map your ER relationships (foreign keys). The reason not to map your foreign keys in your ORM is that you will very likely want to control the fetching and storing of your data on a finer-grained scale unless your database is relatively small and fast. One caveat here is that some ORMS require you to map the foreign keys (ie. they do not provide a means not to). Don't pick these ORMs.
Do not focus on performance at first. Keep a list of the tables / objects that are frequently read and seldom written.
There are many ways to generate your POJOS, here are a couple to get you started. Do some looking around and find one to your liking. I personally like the fluent style so I have listed these first (I have not used these):
Once you have generated your mappings you will still have another class (or classes) to hold some custom db logic (including that logic that makes up for not mapping the foreign keys). This will serve as the glue layer between your app(s) and your ORM.
Lastly, you will have a singleton class that will handle reading the configuration and connecting / disconnecting from your DB. Here is where I inject my encrypted passwords read from a secured auth source as well.
Lastly you will tune for performance. Here is where you will provide some stateless sessions for batch reading of those tables that were frequently read and seldom written as well as for anything that is written and seldom read (g.g. logs). Here you may also need to judiciously introduce some locking.
Depending on the size of your DB and your familiarity with ORMs these steps will take at least one and likely several of those mythical man-months.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I would look to using an ORM. Essentially you could create your entities and models from your database schema. This first step is fairly easy to do with most ORM's. I have done this many times with Hibernate. Focus on keeping things simple. Do not map your ER relationships (foreign keys). The reason not to map your foreign keys in your ORM is that you will very likely want to control the fetching and storing of your data on a finer-grained scale unless your database is relatively small and fast. One caveat here is that some ORMS require you to map the foreign keys (ie. they do not provide a means not to). Don't pick these ORMs.
Do not focus on performance at first. Keep a list of the tables / objects that are frequently read and seldom written.
There are many ways to generate your POJOS, here are a couple to get you started. Do some looking around and find one to your liking. I personally like the fluent style so I have listed these first (I have not used these):
vladmihalcea.com/fluent-api-entity...
github.com/v-ladynev/fluent-hibernate
mkyong.com/hibernate/how-to-genera...
eclipse.org/webtools/dali/docs/3.2...
Once you have generated your mappings you will still have another class (or classes) to hold some custom db logic (including that logic that makes up for not mapping the foreign keys). This will serve as the glue layer between your app(s) and your ORM.
Lastly, you will have a singleton class that will handle reading the configuration and connecting / disconnecting from your DB. Here is where I inject my encrypted passwords read from a secured auth source as well.
Lastly you will tune for performance. Here is where you will provide some stateless sessions for batch reading of those tables that were frequently read and seldom written as well as for anything that is written and seldom read (g.g. logs). Here you may also need to judiciously introduce some locking.
Depending on the size of your DB and your familiarity with ORMs these steps will take at least one and likely several of those mythical man-months.