SQL-Server multi-primary key constraints

A problem found during development last week ~~ When nhib.pdf is used, the problem of multiple constraints in a table is stuck for one day, which may be due to poor foundation ~ I am not familiar with the use of the joint primary key and nhib.pdf. It took a day and wasted a day.
It is very complicated to use the Union primary key in nhib.pdf (I think !), Even brother-in-law also strongly opposed the use of the joint primary key.
The federated primary key is actually not suitable for my needs (I just don't know how to find it in disorder 78. I saw this and thought I could study it in the current project .)
In fact, this concept was quite vague at the beginning. After finding a lot of information, I will summarize it as follows (please correct me if there is any error)
The Union primary key refers to the primary key and foreign key of a table (or any other two or more keys as the Union primary key, which must comply with the primary key constraints of course .) Is to generate a new primary key (conceptual) as a guide.
It is mainly applicable to file management for multiple users. (For example, a simple network hard disk)
Id is the primary key of the table, username needs to be constrained (avoid duplication), FileName is the user-defined file name for upload, each user's own file name cannot be repeated.
Such a structure
Table 1: user table

ID (pk_key/FK)	Username (u)
1	Aaa
2	Bbb

Table 2: file table

ID (pk_key)	U_id (u)	Filename
1	1	Test.jpg
2	1	Abc.jpg

The above data is reasonable and does not violate any constraints.

However, if the data is as follows:

ID (pk_key/FK)	Username (u)
1	Aaa
2	Bbb

Id (PK_key)	U_id (U)	FileName
1	1	Test.jpg
2	2	Test.jpg

In this way, you cannot impose a single constraint on FileName.
There are two solutions: 1. Join the primary key with u_id and FileName.
2. Use multi-key constraints.
The combined primary key is difficult to use in nhib.pdf. To generate a new entity class. The operation is complex. It seems meaningless. In addition, nhib.pdf is not recommended. The definition of Nhibernate is as follows: composite-ID)

<composite-idname="propertyName"(1)class="ClassName"(2)unsaved-value="any|none"(3)access="field|property|nosetter|ClassName"><key-property name="propertyName" type="typename" column="column_name"/><key-many-to-one name="propertyName class="ClassName" column="column_name"/>......</composite-id>

If the table uses the Union primary key, you can combine multiple attributes of the class into the identifier attribute.<composite-id>Element acceptance<key-property>Property ing and<key-many-to-one>Property ing is used as a child element.

<composite-id><key-property name="medicareNumber"/><key-property name="dependent"/></composite-id>

Your persistence class must be overloaded.Equals()AndHashCode()Methods to achieve equivalent identification of the combined identifiers.SerializableInterface

Unfortunately, this combination of keywords means that a persistence class is its own identifier. In addition to the object itself, there is no convenient "handle" available. You must initialize the persistence class instance by yourself and use the combination keywordLoad()Before the Persistence State, you must fill in its Union attributes. We will describe a more convenient method in todo: linktocompenents to implement the Union identity as an independent class. The attributes described below are only valid for this alternative method:

(1)	name(Optional): A component type that holds a union identifier (see the next section ).
(2)	class(Optional) The default value is the property type obtained through reflection (reflection). It is the name of the component class used as the Union identifier (see the next section ).
(3)	unsaved-value(Optional) The default value isnone): If it is setanyValue, which indicates the value that will be held by a newly created instance that has not been persisted.

(Carried from http://www.cnblogs.com/renrenqq)

I am worried about debugging ~

At last, the multi-key constraint is used, which is simple and convenient. It is determined by SQL itself.
The u_id and filename joint constraints are set up to solve this problem :).