Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Including all the records in one table is likely the preferential way to go. It gives you better performance at the cost of size.</p> <p>The performance is arguable depending on how the tables are actually used. If the systems expensive queries doesn't require spots data (like a mass listing), it could potentially be faster not having them on the table, but if you kept the data on table tailoring your query to only pull in the needed data would eliminate the cost of the query almost entirely.</p> <p>I've seen the 1:1 releationship implemented because it makes more sense to a developer than any logical difference in code. Left Outer Joins are more expensive than Inner Joins and Joins are more expensive than no joins.</p> <p>You could potentially decrease the overall database size by not keeping this information on table, but for most small applications (under 1 TB) you should be optimizing for performance.</p> <p>The only real situation that I would think that this set up would be ideal is if you wanted to constrain the type of spots a user can choose from or if the you did a lot of processing on these elements of a dog separately.</p> <p>You can get the same constraining feel by using a lookup table of all possible values and only allowed the user to select from values in the lookup table. Then go back and insert raw values in the dog table. This does does have the side effect of potentially polluting the dog table with data not properly scrubbed by the web app, but it would be a quick effort to isolate what data is not inside of the constraints by comparing to a spot look up table and correcting the issue in the web app.</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