Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The first thing you need to do is step back and consider the problem from the perspective of logical entities.</p> <p>You've identified two entities that I can see - student and submission. "Student" is an obvious entity which you may choose NOT to store in your database, but it may be better that you do. "Submission" is a more obvious one, but what is not so obvious is what a "submission" actually <em>is</em>. Let's assume it is some sort of transaction.</p> <p>You've mentioned a "second table" without a clear indication of its role in the solution. The best I could infer is that it is meant to be some sort of historical trail on activity against a <strong>submission</strong>. If true, then I could envision a physical schema sketched out as follows:</p> <p><strong>Student</strong> table. One row per student; contains information about a student (name, id, etc.). Primary key would probably be an auto-incremented number.</p> <p><strong>Submission</strong> table. One row per submission; includes a foreign key to the <strong>student</strong> table (referencing the primary key); has its own primary key, also an auto-incremented integer. Also has triggers defined for INSERT and UPDATE. INSERT trigger causes INSERT into <strong>submission_log</strong> table; UPDATE trigger also causes INSERT into <strong>submission_log</strong> table.</p> <p><strong>Submission_log</strong> table. One row per event against the <strong>submission</strong> table. Includes all the fields of <strong>submission</strong> plus its own primary key (submission's primary key is a foreign key here), and includes an indicator field for whether it represents an insert or update on <strong>submission</strong>.</p> <p>The purpose of the above is not to supply a solution, or even the framework of a solution, but rather to get you to think in terms of the logical entities you want to model in your solution, and their relationships to each other. When you have a clear picture of the logical model, it will be much easier to determine what tables are required, what their roles are, and how they will be used and how they will relate to each other.</p>
 

Querying!

 
Guidance

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