データベースを設計し、varcharを使用して一意の名前を作成しました。テーブル製品を作成しましたが、各製品には製品コードがあり、このコードは一意であり、繰り返すことはできません。ほとんどの場合、これが親テーブルの主キーです。たとえば、私はキャンドルを持っていて、キャンドルの色が異なるため、製品が異なるため、製品コードによって製品名を区別することができます。int型のインデックス可能なIDとしてテーブルを使用したり、名前を付けたりしませんでした。新しいアイテムが挿入されると、テーブルはauto_incrementsになります。外部キーの他のテーブルへのインデクサーとして一意のコードを使用しました。
これが素晴らしいアイデアかどうかはわかりません。私はPHPMySQLを初めて使用し、異なるテーブルに値を挿入する際に問題が発生したため、製品コードを使用して両方をリンクします。今、私はずっと前に私の問題を解決することができたmysqli_insert_idのものについて知っていました。
したがって、int型の行IDよりも文字列の非標準の行IDを使用できますか？
個人的にはautoincIDを使うと思います。製品コードをID/主キーとして使用するということは、後で製品コードを変更できない（または変更が難しくなる）ことを意味し、問題を引き起こす可能性があります。
詳細に：
製品がさまざまなテーブルにリンクされるようにデータベースを拡張することになった場合、IDとして製品コードを使用すると、製品コードを変更する場合は、すべてのテーブルの各エントリを更新する必要があります。製品コードではないIDを使用するということは、コードを1か所（在庫テーブル）で更新するだけでよく、在庫テーブルに参加して製品コードを取得するときにIDが残りの作業を行うことを意味します。
文字列IDの大きな欠点は、インデックスが（はるかに）大きくなり、パフォーマンスに影響を与える可能性があることです。
私はそれを単純に保ち、標準の自動インクリメントintを使用します。
私は@hd1と@webnoobの回答にも同意します-行IDは一定であり、それが説明する値から独立している必要があります-古典的な間違った（私の意見では）行IDはアメリカのSSNまたは政府によって人や会社に割り当てられた他の一意の番号です。
一意の[理想的には変化しない]値のグループは、データベースのキー/主キーとして使用できます。サロゲートキー[例：自動インクリメントされたINT列]がmySQLで非常に一般的である主な理由は、次の理由によるものです。
name長さが5の列のキーが名前Tom Cruiseに衝突しTom Clancy、キーが。であるためTom C。自然キーと代理キーの長所と短所は、リレーショナルデータベースがある限り議論され続けます。私は言います：好きなことをしますが、サロゲートを使用する場合は、可能であれば、自然キーを使用して行を一意に識別する方法もあることを確認してください。
文字列を解析して同等化する必要があります（クエリ、結合など）。したがって、パフォーマンスに影響があります。これは、可能であればそれを避けるべきであることを意味します。
あなたはそれを行うことができますが、あなたができるという理由だけで、あなたがすべきだという意味ではありません。理論的には、主キーはデータベースの外部では意味を持ちません。製品コードは、定義上、データベースの外部で意味を持ちます。