Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Composite keys should never be considered in "new" applications. They were used in the past, by people who used to think that "business keys" are better than "surrogate keys". </p> <p>Edit: As asked by Chris, I'm expanding my answer.</p> <p>Let me start by stating that I understand this question as "Composite Primary Keys" vs. "Surrogate keys". </p> <p>Also, I concede that there is <em>one</em> use case where a composite key makes sense: in cross reference tables, also called "link tables". These are used in many-to-many tables and consists in only two fields, both foreign keys that form a primary key for the xref table. For instance, <code>UserRole</code> table would contain <code>user_id</code> and <code>role_id</code>, nothing else. There's no class representation in Java, for instance, for a table like this. This is usually a <code>@ManyToMany</code>, with a <code>Collection</code> in both sides. </p> <p>I shared my views on Natural keys vs. Surrogate keys in another answer ( <a href="https://stackoverflow.com/questions/4577754/hibernate-opinions-in-composite-pk-vs-surrogate-pk">Hibernate : Opinions in Composite PK vs Surrogate PK</a> ) , and I believe that Composite keys shares some of the disadvantages of the Natural key, without bringing any real benefit. </p> <p>The problem with composite keys is that you'll need <em>two</em> values to uniquely identify a record. This becomes a problem once you start having tables which references records in this first table. The second table then needs <em>two</em> columns to be able to reference <em>one</em> record. And if this second table uses a composite key made up of a single value + the foreign key, you now have <em>three</em> columns to uniquely identify <em>one</em> record. And a third table would need these <em>three</em> extra columns just to reference <em>one</em> record in the second table. Really, this is a snow ball. </p> <p>Another disadvantage is that requirements <em>do</em> change. All the time. So, what seems to be a good composite key today is not a key at all tomorrow. That's why we have surrogate keys: to be future-proof. </p> <p>Composite keys are mainly used so that records in a table are unique based on a set of columns. For instance, if you have a <code>Customers</code> table, you may have a <code>NationalId</code>+<code>Country</code> as a unique value, meaning that two users cannot share the same SSN if their country is USA. But it's possible to have the same number for two records, if they are not in the same country. If you like composite keys, this would be a good candidate for it. But as I hinted earlier, you can use a surrogate key and apply a <code>unique</code> constraint. You'll have the benefits of a composite key plus the safety of a surrogate key. </p>
    singulars
    1. This table or related slice is empty.
    1. POUnder what condition we need to use composite keys in database
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USjpkrohling
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POUnder what condition we need to use composite keys in database
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COPlease expand as to why. Also, see symcbean and respond.
      singulars
      1. PO
      1. USChris Cudmore
    2. COI just expanded my answer. It's bigger than I wanted, but I hope that this explanation is enough :-)
      singulars
      1. PO
      1. USjpkrohling
 

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