Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I'm not sure from your description where the duplicate-data problem is. You have:</p> <ul> <li>Table 1: procedures. Could be lots of rows for same physician</li> <li>Table 2: physicians. Should be 1 row per physician (but there may be duplicates)</li> </ul> <p>The relationship that would make sense would be 1[table 2 physician row] -> many[table 1 procedures rows]. i.e. table 2 would be the primary key table in the relationship: each table 2 row relating to between 0 and "many" table 1 rows. If you try to create this kind of relationship, then multiple duplicate table 1 rows are not a problem.</p> <p>If, however, you have multiple rows per physician in table 2, then you won't be able to create this kind of relationship, because table 2 rows are not unique and thus can't act as the primary key element in the relationship. The problem then is one of data-cleansing: figuring out which rows in table 2 are duplicates, updating the table 1 rows to point to just ONE physician out of the duplicates, and then deleting the duplicate rows from table 2.</p> <p>You mention physician ID#s and physician names. Physician name would be a bad choice for a unique key; if a user tries to add a new physician called "John Smith" when there already is another physician of that name, either</p> <ol> <li>You've set up a unique index on PhysicianName, their change gets rejected, and you have an irate user; or</li> <li>You haven't, and all the existing physician's (let's call him John A. Smith) procedures will be associated with the other physician (let's call him John B. Smith) and vice versa.</li> </ol> <p>The relationship should be set up using the physician ID. If Table 1 (Procedures) includes a physician ID column, you're in luck. If it only includes physician Name, then you may have a data-cleansing problem, if there are already duplicate physician Names in Table 2.</p>
    singulars
    1. This table or related slice is empty.
    1. POSQL DB table Relationship
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USsebt
    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. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

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