I love this place!
Sean Clark wrote:Hey,
You can do an sql query that will join the 2 tables and this will allow you to get all the information out in 1 SQL statement so that you can fill your objects.
w3schools has a good tutorial on this: http://www.w3schools.com/Sql/sql_join.asp
Sean
James Clark wrote:The better method is to use a ORM framework such as Hibernate and avoid "hand-written" SQL statements.
P Uk wrote:
James Clark wrote:The better method is to use a ORM framework such as Hibernate and avoid "hand-written" SQL statements.
This may sound ridiculous but I welcome comments on it: One of the reasons I've been avoiding an ORM framework is because I've spent so much time learning other stuff already that I'm not actually getting anywhere with the project. Are ORM frameworks designed to help with situations I'm talking about? For instance, the ability to return thousands of Person objects in just one SQL query and when attributes of that person object are requested that aren't in the main table, then to do the "sub" queries? If that's a fundamental aspect of them, then I might be interested in looking further!
Something for me to bear in mind, but I would worry that would get unscalable: especially when a person is linked to other things too. There'd be a lot of redundant data and nulls in the result set.
Are ORM frameworks designed to help with situations I'm talking about?
I love this place!
P Uk wrote:
Sean Clark wrote:Hey,
You can do an sql query that will join the 2 tables and this will allow you to get all the information out in 1 SQL statement so that you can fill your objects.
w3schools has a good tutorial on this: http://www.w3schools.com/Sql/sql_join.asp
Sean
Thanks for the reply. Something for me to bear in mind, but I would worry that would get unscalable: especially when a person is linked to other things too. There'd be a lot of redundant data and nulls in the result set.
SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Kengkaj Sathianpantarit wrote:
I recommend to just use SQL JOIN.
Regarding scalability, it depends on the number of person. If there are a lot of person, you should not have findAll(), but should use a pagination method like findAll(int limit, int offset). I don't know what you mean by redundant data and nulls.
James Clark wrote:This relational model looks sloppy ROLE_CODE should not be in this table. It should be in another table with a link to PERSON.ID column.
Your "repetition" of data stems from a sloppy relational design. If you improve this a little, then you eliminate the redundant data and
will be able to see better SQL statements in the future.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
James Clark wrote:
It is difficult to associate a realistic business requirementt that would ask for "all the persons and their roles."
Jelle Klap wrote:If you want to avoid having to learn yet another framework (ORM solution), and stick with plain JDBC instead, I'd suggest you take a look at the Interpreter pattern, like David Newton suggested. In addition to giving you more control over what is retrieved from the database and what is not, by dynamically building up the SQL join query, it will also keep the DAO interface clear and concise. It may not be as ideal a solution as the lazy loading approach offered by most ORM frameworks, but if you need to move forward now, using technologies that you are already familiar with, it might be a good fit.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
David Newton wrote:Hibernate has more functionality than JPA. EJB3 is a different issue altogether--and while it's significantly better than previous versions, if you don't need it, why learn it?
Jelle Klap wrote:Well, you should view JPA as a specification.
<snip>
Kengkaj Sathianpantarit wrote:Well, I think you should define what is the problem first. If you think redundant data is the problem, ORM doesn't help anything.
Data will be redundant anyway for one-to-many relations because ORM also uses SQL JOIN (in case you want data from different tables). ORM helps to map relational data to objects, it does what you're doing manually.
SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Ben Narendren wrote:Hibernate is a very good bet for your situation. The simple answer to your question is to apply the Data Mapper pattern (refer Patterns of EAA by Fowler). But instead of reinventing the wheel, you might as well use Hibernate which has a very good implementation of Data Mapper. Hibernate supports
1) Lazy Loading
2) You can specify which objects you want to eager fetch
3) If these objects have a child hierarchy you can setup the depth to which you want to fetch
4) In addition, Hibernate gives you a lot of out of the box functionality which you will need implement a DAO pattern effectively