Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Object Model vs Data Model

 
anuj bhatnagar
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
a
 
K. Tsang
Bartender
Posts: 3440
13
Android Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
anuj bhatnagar wrote:Table - Business_Info (id,name,code,type,parentId)

Class Business which has the similar fields as in Business_Info table but the objects of Business can be logically be of three types Enterprise, Division or an Originator from the logical point which is determined by parentId field.


You mentioned "types" enterprise, division, originator. Then a Enum can be a viable option. Not knowing exactly your requirements and how "similar" will say EnterpriseBusiness class be with Business_Info class. Also rather than an abstract class approach, you may want to consider interface approach. The classic abstract class vs interface issue.
 
anuj bhatnagar
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
b
 
K. Tsang
Bartender
Posts: 3440
13
Android Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I get what you are trying to do. Yet choosing the best approach needs to weigh in the pros and cons.

From your Business_Info table, the "type" field can surely be a constant (Enum). Say the sample data looks like:
id,name,code,type,parentId
1,abc,somecode,business,1
2,pqr,somecode,division,2
3,xyz,somecode,originator,3
4,sub-bus,somecode,business,1
5,sub-div,somecode,division,2
6,sub-org,somecode,originator,3

Then the parentId is simply foreign key to the id field. And in coding, you will then need some sort of Business Delegate object to determine what kind of Business_Info that DB record is and perform the necessary business logic for that particular type.
 
anuj bhatnagar
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes that makes sense but how about adding a new business type into the system. Wouldn't it require Enum change?
And how do we handle a case when one of the Business Type require one extra field?
 
K. Tsang
Bartender
Posts: 3440
13
Android Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
anuj bhatnagar wrote:Yes that makes sense but how about adding a new business type into the system. Wouldn't it require Enum change?
And how do we handle a case when one of the Business Type require one extra field?


You can have another table storing such constant then use a POJO to retrieve it rather than so-called hard-coding in code.
 
anuj bhatnagar
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
K. Tsang wrote:
anuj bhatnagar wrote:Yes that makes sense but how about adding a new business type into the system. Wouldn't it require Enum change?
And how do we handle a case when one of the Business Type require one extra field?


You can have another table storing such constant then use a POJO to retrieve it rather than so-called hard-coding in code.


Oh Ok. Thanks I think I got the answer if what I was looking for.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic