StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
61103
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2008-09-14T03:34:11.817
FavoriteCount
0
LastActivityDate
2008-09-14T03:34:11.817
LastEditDate
LastEditorUserId
0
OwnerUserId
5878
ParentId
38352
PostTypeId
2
Score
7
ViewCount
0
LastEditorDisplayName
text
Body
<p>Consider two tables for People and their addresses: </p> <pre><code>People (pid, prefix, firstName, lastName, suffix, DOB, ... primaryAddressTag ) AddressBook (pid, tag, address1, address2, city, stateProv, postalCode, ... ) </code></pre> <p>The Primary Key (that uniquely identifies each and every row) of People is <code>pid</code>. The PK of AddressBook is the composition of pid and tag <code>(pid, tag)</code>.</p> <p>Some example data:</p> <h2>People</h2> <pre><code>1, Kirk 2, Spock </code></pre> <h2>AddressBook</h2> <pre><code>1, home, '123 Main Street', Iowa 1, work, 'USS Enterprise NCC-1701' 2, other, 'Mt. Selaya, Vulcan' </code></pre> <p>In this example, Kirk has two addresses: one 'home' and one 'work'. One of those two can (and should) be noted as a foreign key (like a cross-reference) in <code>People</code> in the primaryAddressTag column.</p> <p>Spock has a single address with the tag 'other'. Since that is Spock's only address, the value 'other' ought to go in the <code>primaryAddressTag</code> column for pid=2.</p> <p>This schema has the nice effect of preventing the same person from duplicating any of their own addresses by accidentally reusing tags while at the same time allowing all other people use any address tags they like.</p> <p>Further, with FK references in <code>primaryAddressTag</code>, the database system itself will enforce the validity of the primary address tag (via something we database geeks call referential integrity) so that your -- or any -- application need not worry about it.</p>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POAddress book DB schema
  singulars
  PostTypePostTypeId
  PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USAlan
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POAddress book DB schema
  singulars
  PostTypePostTypeId
  PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
  singulars
  PostPostId
  PO
  UserUserId
  This table or related slice is empty.
  VoteTypeVoteTypeId
  VTUpMod
2. VO
  singulars
  PostPostId
  PO
  UserUserId
  This table or related slice is empty.
  VoteTypeVoteTypeId
  VTUpMod
3. VO
  singulars
  PostPostId
  PO
  UserUserId
  This table or related slice is empty.
  VoteTypeVoteTypeId
  VTUpMod
CommentsPostId
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.