Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I am not entirely sure about your actual <em>question</em>. The lack of question marks makes that a bit hard to understand - I will try to respond what seemed the question, however.</p> <p>Medical Records, Doctors and Patients are all potentially aggregate roots with respect to something: They all exist in the real world, you can even touch them and each of them 'aggregate' other objects or pieces of information. However, you might not need to model objects to the degree where they actually become aggregate roots - that depends on the exact requirements of your application.</p> <p>These entities do not aggregate each other, however. Doctors can exist without medical records and so do patients. The pity is that medical records need both patients <strong>and</strong> doctors so they cannot be aggregated by either one. Thus, they become an Entity.</p> <p>Each of the beforementioned must have their own identity. Note that these objects live on even if their associated items don't. Most obviously, the doctor stays in the system even if the patient does not, but more importantly, the documents also live on (and might keep both patients and doctors from being deleted, but that is another issue).</p> <blockquote> <p>I still identify vitals in the database with its own key</p> </blockquote> <p>After all, you need to store a list of Vitals for each patient. Since you are probably using SQL, you'll probably want to model this m:n relation using a linker table, so you'll have to assign a key. That is OK. It's a shortcoming of the persistence layer, not of the model, but you should make sure never to use this key for anything but internal application purposes.</p> <blockquote> <p>therfore does that mean Encounter is not an Aggregate Root</p> </blockquote> <p>An "Encounter" is certainly not an aggregate root with respect to doctors or patients: It's again an m:n relation, this time between doctors and patients, so obviously there will be many encounters per patient and per doctor. If one of the encounters was deleted (because they were incorrect, for example) this would not delete the patient or the doctor. Also, an <code>Encounter</code> is not an aggregate root for a prescription: An X-Ray, for example, is something that makes perfect sense on its own. However, you might want to keep a reference. Again, deleting the <code>Encounter</code> in the future won't revert the X-Ray.</p> <p>Encounters don't own doctors or patients. Neither do doctors 'own' encounters. </p> <p>Also note that an encounter <em>might</em> lead to medicine being prescribed, or might not lead to anything.</p> <p><strong>NOTE</strong> Your method <code>AddBP()</code> will effectively delete the old value, so it should not be named 'add'. More importantly, this method makes the <code>Vital</code> class mutable and thus much more complicated. I'd get rid of that method.</p>
    singulars
    1. This table or related slice is empty.
    1. PODDD and distinction between Entity and Value object. Choosing the aggregate root
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USmnemosyn
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PODDD and distinction between Entity and Value object. Choosing the aggregate root
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI apologize for the lack of a clear question. I understand that patient and doctors would be aggregate roots. It is true that doctors create Medical records for given patients, therefore does that mean it does not make sense to retrieve medical records outside the context of a patient. Also in the case of a prescription, if a business rule exist that for every prescription there must be a valid encounter, then does encounter just become a property of the prescription
      singulars
      1. PO
      1. USWilliam
 

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