問題タブ [primary-key]

たとえば、自動採番フィールドがある場合、このフィールドを指定せずに新しいレコードを追加し、DB エンジンに選択させます。
では、削除されたレコードの番号を取得しますか? はいの場合、いつですか？

// SQL サーバー、MySQL。///

フォローアップの質問: DB エンジンが主キーに使用する数を使い果たした場合はどうなりますか?

DBは削除されたレコードの数を再利用しないため、特にこの列に実際には大きな整数型を選択しない場合は、数が不足する可能性があります。
何が起こり、それが悪い場合にそれを防ぐ方法は？

// SQL Server、MySQL //

私は現在、テーブル名のリストと最後に使用された主キーを含むルックアップテーブルを介して主キーが生成される他の誰かのデータベースで作業しています。ストアド プロシージャは、この値をインクリメントし、呼び出し元の「挿入」SP に返す前に一意であることを確認します。

ID/自動番号を使用する代わりに、このような方法を使用する (または単に GUID を生成する) ことの利点は何ですか?

ISBN や製品コードのようなものを実際に「意味する」主キーについて話しているのではなく、一意の識別子について話しているだけです。

ありがとう。

データベースに日付をテキストで表すテーブル（つまり「2008-11-09」）があり、それらをUNIXタイムスタンプに置き換えたいと思います。ただし、MySQLが単独で変換を実行できるとは思わないので、変換を実行するための小さなスクリプトを作成したいと思います。私がそれを行うと考える方法は、テーブル内のすべてのレコードを取得し、それらを反復処理し、データベースレコードを更新することです。ただし、主キーがないと、更新する必要のある正確なレコードを簡単に取得できません。

UPDATEを実行するときにレコードを参照できるように、SELECT中にMySQLにレコードに一時IDを割り当てる方法はありますか？

ハイ/ロー アルゴリズムとは何ですか?

これはNHibernateのドキュメント (一意のキーを生成する方法の 1 つ、セクション 5.1.4.2) で見つけましたが、それがどのように機能するかについての適切な説明は見つかりませんでした。

Nhibernate が処理することは知っています。内部を知る必要はありませんが、気になるところです。

現在のプロジェクトで、マスター DB スクリプトに出会いました。よく見てみると、元の主キーはすべて数値型 (38,0)で あることがわかりました。現在、プライマリ DB プラットフォームとして SQL Server 2005 を実行しています。

少し説明すると、バックエンドとして Oracle と SQL Server の両方をサポートしています。Oracle では、主キーのデータ型は数値 (38,0) です。

そのような実装の可能性のある副作用とパフォーマンスへの影響を知っている人はいますか? 私は常にintまたはbigintを主キーとして提唱し、実装してきました。

私は自分のデータベース（Oracle）を設計する必要があるプロジェクトのこの時点にいます。通常、ステータス テーブルと国テーブルでは、数値の主キーは使用しません。たとえば、

これらのテーブルは静的であり、アプリケーションを通じて更新されず、将来変更されることは予測されないため、これらの値を外部キーとして使用するテーブルで更新の問題が発生する可能性はありません。

アプリケーションのメイン テーブルは、ステータスと国 (複数回、例: 出発地の国、目的地の国) を使用し、年間 600000 行が追加されることが予想されます。

私の質問は、これらの VARCHAR(2) キーは、3 つのテーブルの結合をクエリするときにパフォーマンスに影響を与えるでしょうか。最初のものは 2 番目のものよりも大幅に遅くなりますか?

説明:

ステータスはバイナリではありません (テーブル名の横にある「最大 6」)。値はおそらく次のようになります。

デコードされた値をユーザーに表示する必要があるため、名前が必要です。

MySQL で主キーとして INT と VARCHAR を使用する場合、測定可能なパフォーマンスの違いはありますか? 参照リスト (米国の州、国コードなど) の主キーとして VARCHAR を使用したいのですが、同僚はすべてのテーブルの主キーとして INT AUTO_INCREMENT を使いません。

hereで詳しく説明されているように、私の主張は、INT と VARCHAR のパフォーマンスの違いはごくわずかであるということです。すべての INT 外部キー参照では、参照を理解するために JOIN が必要になるため、VARCHAR キーは情報を直接提示します。

では、この特定のユースケースとそれに関連するパフォーマンスの問題を経験した人はいますか?

ORM として TopLink を使用し、DB として MySQL を使用しています。

テーブルの 1 つで、自動インクリメント主キーを GUID と交換しました (まあ、そうではありません。実際にはランダムな 64 ビット整数を使用していますが、それで十分です)。

とにかく、キーさえ使用しないクエリは、はるかに時間がかかります。

私に何ができる？

いくつかのデータテーブルを含む小さなデータセットがあります。さまざまなDBからデータテーブルをロードし、特定のデータテーブルに適用する主キーを決定するために読み取った構成ファイルを持っています。構成に適切な (一意ではない) 主キーが含まれていない場合、主キーをデータテーブルに適用するときにこのイベントをキャッチするにはどうすればよいですか? 現在、一意ではありませんが、主キーを適用できるようです....

誰かが私が欠けているものを指摘していますか? ありがとう