他のすべてのテーブルの主キーとして GUID を使用していますが、増分番号が必要な要件があります。自動インクリメントを使用してテーブルにフィールドを作成しようとしましたが、MySql はそれが主キーである必要があると不平を言いました。
私のアプリケーションは ORM として MySql 5, nhibernate を使用しています。
私が考えた可能な解決策は次のとおりです。
主キーを自動インクリメント フィールドに変更しますが、ID を GUID として保持しているため、アプリの残りの部分は一貫しています。
GUID と自動インクリメント フィールドの両方で複合キーを作成します。
現時点での私の考えは、複合キーのアイデアに傾いています。
編集: 行 ID (主キー) は現在 GUID です。人間が読めるように、自動インクリメントされる INT フィールドを追加したいと思います。GUIDを主キーとして持つアプリの現在の標準から離れたくありませんでした。
GUID 値は、テーブルやデータベース全体で一意であることを意図しているため、auto_increment 列をプライマリ インデックスにし、GUID の UNIQUE インデックスを作成します。
私は反対に傾くでしょう。
なんで？複合キーを作成すると、テーブルに同じ GUID が 2 回あってもシーケンス番号が異なっても問題ないという印象を次に来る人に与えるためです。
GUIDは注文可能であることを意図しAUTO_INCREMENTていないため、意味がありません。
ただし、テーブルAUTO_INCREMENTの複合主キーの 2 番目の列に を使用することはできます。MyISAM列に対して複合キーを作成し(GUID, INT)、2 番目の列を にすることができますAUTO_INCREMENT。
新しい を生成するには、ステートメントまたはトリガーでGUID呼び出すだけです。UUID()INSERT
いくつかの考え：
GUID が完全にインクリメンタルで一意である場合、それを実際の主キーにしないのはなぜでしょうか?
一方で、プログラムの問題に基づいて意味論的な決定を下すべきではありません。DB の設計ではなく、MySQL に問題があります。
したがって、ここでいくつかの回避策を示します。
挿入後に GUID を適切な値に設定するトリガーを作成します。これは、スキーマのセマンティクスを変更することなく、MySQL の問題に対する MySQL ソリューションです。
挿入する前に、トランザクションを開始し (自動コミットが false に設定されていることを確認してください)、最新の GUID を見つけて、新しい値でインクリメントおよび挿入します。つまり、自動インクリメントは自動的ではありません:P
いいえ、値として auto_increment を持つことができるのは主キーだけです。
何らかの理由で ID 列を主キーに変更できない場合は、ある種の SEQUENCE テーブルと SEQUENCE テーブルにクエリを実行し、次に使用する値を保存するためのトリガーを介して自動インクリメントを手動で生成するのはどうでしょうか。次に、トリガー内の宛先テーブルに値を割り当てます。同じ効果。私が持つ唯一の質問は、自動インクリメントされた値が、テーブルを再選択せずに NHibernate を介して元に戻るかどうかです。