Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The best choice largely depends on what you want to do, thus what queries you would be running (as with many things).</p> <p>I don't quite understand the WordPress one (I get the fact that you store individual fields as rows, but I don't know where it fits in), so I'll just list all the options:</p> <ol> <li>Have user and history tables store individual fields per row</li> <li>Have only history table store individual fields per row</li> <li>Have only user table store individual fields per row</li> <li>Have neither store individual fields per row</li> <li>Have 1 combined table for both user and history</li> <li>Have 1 combined table for both storing individual fields per row</li> </ol> <p>(5) and (6) doesn't really seem like options in most cases, as I suspect you'd want to get the details for a user (or a bunch of users) more often than you would want to get the history (unless most of your queries is to get both at the same time).</p> <p>(1) and (3) are not advised, unless many of the details are not filled in (thus you'd end up with very sparse tables in other cases).</p> <p>(4) is for when users tend to change all their details at once, which probably doesn't happen often, I suspect people just change 1 or 2 fields at a time. So, (2) is probably a better option, especially if the user table has many fields (and people just change 1 or 2 fields at a time).</p> <p>Generally, storing individual fields per row is for reduced storage space above performance (assuming there are some empty fields, otherwise storing individual fields per row is hands-down worse), you basically determine which is best by looking at your requirements and the expected data. Note we're talking mainly about selecting here, which is generally the slow operation, unless you have some weird stuff going on, or tons of inserts at once. For history, reduced storage is generally preferred above performance, so (2).</p> <p>Adding fields is generally a bit of effort in anyway, so just saying 'UPDATE user ADD COLUMN col' is not really a big deal, it can even be automated. This would be another (small) reason to prefer (2) above (4).</p>
    singulars
    1. This table or related slice is empty.
    1. POWhich layout for user-data plus a change-log is the most efficient and less storage consuming?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USDukeling
    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. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    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