Databases
StackOverflow2013
Postsdbo
POimplementing relationships between entity classes w/out ORM
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POimplementing relationships between entity classes w/out ORM
    primarykey
    data
    text
    <p><br /> I have some entity classes that have one-to-one and/or one-to-many relationship with other entities.</p> <p>I try to make a quite generic example that reflects my case... let's say that I have the following tables stored in a DB (no null values allowed):</p> <pre><code> operations (ID, workerID, customerID, etc_etc) workers (ID, email, password, etc_etc) customers (ID, etc_etc) mobilePhones (workerID, phoneNumber) </code></pre> <p>It should be quite clear that:</p> <ul> <li><strong>1</strong> operation has <em>only</em> <strong>1</strong> worker and <strong>1</strong> customer.</li> <li><strong>1</strong> customer has <em>at least</em> <strong>1</strong> mobile phone number.</li> </ul> <p>Thus I have the following entity classes:</p> <pre><code>public class Customer { private int id; //other fields, then constructors, getters and setters } public class Worker { private int id; //other fields private String[] mobilePhones; } </code></pre> <p>As I already said in the title, <strong>I can't use ORM</strong> such as Hibernate, so I'm going to use DAOs.<br /> <em>{ <strong>EDIT:</strong> I should have known you were curious to know why I can't use ORM... well, as I wrote in a comment down here:</em> It's an assignment (a project for a Software Engineering exam)<em>. }</em></p> <p>Now, I guess I'm not going to have any problem with <code>WorkerDAO</code>, that can easily manage the one-to-many relationship by selecting from <code>mobilePhones</code> all phone numbers where <code>workerID</code> equals the actual worker's id.</p> <p>The real problem for me is how to manage the relationships between an <code>Operation</code> and its associate <code>Worker</code> and <code>Customer</code>. Provided that I would like to avoid waste of memory, should I design my <code>Operation</code> entity like this:</p> <pre><code>public class Operation { // here I have some doubts private int id; private int workerId; private int customerId; //other fields } </code></pre> <p>or maybe like this:</p> <pre><code>public class Operation { // here I have some doubts private int id; private Worker worker; private Customer customer; //other fields } </code></pre> <p>?</p> <p>The latter seems to be more <em>Object Oriented</em> but has one trivial implication: the instances of worker and customer must be in memory, even if the clients of <code>Operation</code> may not need them.</p> <p>Even worse: if <code>OperationDAO</code> sets worker and customer as new Worker and Customer instances, this will lead to keep in memory <em>several instances referring to the same worker/customer</em> (e.g. two operations performed by the same worker). Beside the waste of memory, this could definitely lead to <em>inconsistency of data</em> (e.g. one instance being modified without updating the others).</p> <p>In order to avoid this, there should be introduced some class that is aware of which instances are currently loaded (e.g. using something like <code>List&lt;Worker&gt;</code>, <code>List&lt;Customer&gt;</code>, etc)... and honestly this seems to me to be an overkill.</p> <p>I also thought I could try to implement some kind of <em>lazy fetching</em>, e.g. setting worker instance only at the first request, but still I would need some class that tracks what is in memory and what has to be queried; I wouldn't even know if this class should be related to <em>Data Access Logic</em> or to <em>Business Logic</em> (I'd guess the former but still not sure).</p> <p>Anyway there's just no reason to implement all this, since I don't need a caching system (and I feel like it would seem much like that).</p> <p>Any suggestion?</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. UStmh
    1. UStmh
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POimplementing relationships between entity classes w/out ORM
      1. UStmh
      1. VTFavorite
    2. VO
      singulars
      1. POimplementing relationships between entity classes w/out ORM
      1. This table or related slice is empty.
      1. VTUpMod
    1. COJust curious to know why can't you use ORM?
      singulars
      1. POimplementing relationships between entity classes w/out ORM
      1. USVikdor
    2. COIt's an assignment (a project for a Software Engineering exam).
      singulars
      1. POimplementing relationships between entity classes w/out ORM
      1. UStmh
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload