複数のフィールドの一意性を定義する方法はわかりません。Doctrine複合キーとUniqueConstraintの比較
私は次の両方の例がその仕事をしていますか？
違いは何ですか、好きなのは何ですか？
まず1：
/** @ORM\Id */
private $id;
/** @ORM\Id */
private $title;
第二1：
/** @ORM\Table(name="productitem", uniqueConstraints={@UniqueConstraint(name="product_unique", columns={"id", "title"})})
*/
class ProductItem
{
private $id;
private $title;
}
あなたのタイトルはあなたが外の複合キーを作成する必要はありません、あなたの種類の製品の上に一意であることを確認したい場合タイトルとID。
商品のタイトルが一意であることが確かであれば、単にtitleをキーとして直接使用することができます。しかし、エンティティのライフタイムを主キーとして変更する可能性のあるものを使用することは推奨されません（また、製品タイトルはもちろん生涯にわたって変更される可能性があります）。そのような場合は、識別子（代理キー）を持つ別の列を使用する方が良いです。
unique属性でタイトルを一意であるとマークするだけで、このためにUniqueConstraintを使用する必要はありません。詳細についてはthe Doctrine documentation chapter: 21.2.1. @Columnを確認してください。
だから私は、次のことをお勧め：私は、PostgreSQL DBでの私のテストから結論している
/**
* @ORM\Id
* @ORM\Column(type="int")
*/
private $id;
/**
* @ORM\Column(type="string", unique=true)
*/
private $title;
、その：（複数のプロパティは、この注釈を共有する場合、複合）
@Id主キーを作成し
ユニークなインデックスはユニークなインデックスを作成します
いずれも一意性を保証します。そして私がそれを正しく理解すれば、主な違いはプライマリ・キーはnull値を持つことができないということです。
あなたのIDは生成された値ですか？自動インクリメントか単純な値/文字列ですか？おそらく、データのプレビューとしていくつかの例を挙げることができますので、ユースケースをソートするのが簡単です。 – Kwido
私は一般的な概念にもっと興味があります。関連するすべての側面の主な違い。最初に使用する場合、2番目に使用する場合、組み合わせはいつですか？ – Neon
複合キーの使用に対するDoctrine docのアドバイスに注意してください。 – Veve