Java – under what conditions do we need to use composite keys in the database

I've seen that we can use compound keys, where the primary key consists of a combined primary key of two tables

Like people and books

person_id and book_id will make the primary key.

But I want to ask, we need a hard coded programming language

I mean, I can use a separate column of any name as the primary key, and then I don't have to hard code it. I can perform my functions as usual

id,person_id,book_id

Solution

Composite keys should never be considered in "new" applications People who used to use them once thought that "business key" was better than "agent key"

Editor: as Chris asked, I'm expanding my answer

First, let me explain that I understand this problem as "composite primary key" and "proxy key"

In addition, I admit that there is a use case where composite keys make sense: in cross reference tables, also known as "linked tables" They are used in many to many tables and contain only two fields, both of which are foreign keys that form the primary key of the XRef table For example, the userrole table will contain user_ ID and role_ ID, nothing else For example, for a table like this, there is no class representation in Java This is usually @ manytomany, and both sides have a collection

In another answer (Hibernate: options in composite PK vs surrogate PK), I shared my views on natural keys and proxy keys. I believe that composite keys have some disadvantages of natural keys and do not bring any practical benefits

The problem with composite keys is that you need two values to uniquely identify records This becomes a problem once you start having tables that reference records in the first table Then the second table needs two columns to reference a record If the second table uses a composite key consisting of a single value as a foreign key, there are now three columns that uniquely identify a record The third table requires these three additional columns to reference a record in the second table Really, this is a snowball

Another disadvantage is that requirements change at all times. Therefore, today seems to be a good composite bond, not the key to tomorrow That's why we have proxy keys: for the future

Composite keys are mainly used so that records in the table are unique based on a set of columns For example, if you have the customers table, you might use the nationalid country as the unique value, which means that if two users' country / region is the United States, they cannot share the same SSN However, if the two records are not in the same country, the same number can be used If you like compound keys, this will be a good choice But as I suggested earlier, you can use proxy keys and apply unique constraints You will gain the benefits of composite keys and the security of proxy keys