2

私は現在mysqlを使用してプロジェクトを行っており、完全な初心者です.....

次の列でテーブルを作成しました.....

            ID           // A integer type column which is a primary key........
            Date         // A Date type column.........
            Day          // A String column.........

ID 今、列の挿入値が自動的に生成される方法が存在するかどうかを知りたいのですが......??

date - 4/10/1992例: - 値としてandを挿入したDay - WED場合。Mysql サーバーは、整数値が存在するかどうかのチェックから開始して、整数値を自動的に生成する必要があります。1 つまり、値を含むテーブルで

             ID              Date              Day

             1              01/02/1987         Sun
             3              04/08/1990         Sun

上記の表に日付値と日付値 (例で指定) を挿入するとします。次のように挿入する必要があります

             2              04/10/1992         WED

自動インクリメンタを使用するような方法を試しました.....しかし、ID値をインクリメントするだけではないのではないかと心配しています。

4

3 に答える 3

1

これを行う方法はありますが、パフォーマンスに影響します。最初の挿入のためだけに、またはより速く挿入したい場合のために、列にauto_incrementを保持してください。

列にauto_incrementがある場合でも、既存の値と衝突しない限り、値を指定できます。

次の値または最初のギャップを取得するには：

SELECT a.ID + 1 AS NextID FROM tbl a
LEFT JOIN tbl b ON b.ID = a.ID + 1
WHERE b.ID IS NULL
ORDER BY a.ID
LIMIT 1

空のセットを取得した場合は、1を使用するか、auto_incrementに処理を任せます。

同時実行のために、他のセッションが見つけた次のIDを使用しないように、テーブルをロックする必要があります。

于 2012-06-23T14:04:18.017 に答える
1

まあ...私はあなたの問題を理解しました...あなたはそれが制限を制御できるような方法でエントリを生成したいです...

さて、私は非常に奇抜な解決策を持っています...気が向いたらそれを受け入れるかもしれません....

unsigned int を使用して自動インクリメント モードで主キーを使用してテーブルを作成します (ここで提案されているように)...

ここで、2 つの状況を考えてみましょう....

テーブルを毎年または特定の期間内にクリアする必要がある場合 (そのような状況が存在する場合)... perform alter table自動インクリメント モードを無効にしてすべてのコンテンツを削除する操作...そして再度有効にする......

あなたがしているのはある種のデータウェアハウジングである場合.....データベースを何年も....sql query to find the smallest primary key value using predefined key functions挿入する前にaを含め、それが2 ^ 33を超える場合は create a new table with the same details、そうする必要がありますmaintain a seperate table to track the number of tables of this types

トリックは少し複雑で、恐れています....あなたが期待したような単純な方法は存在しません....

于 2012-06-28T15:54:38.960 に答える
0

整数の主キー列から値を削除することによって作成されたギャップをカバーする必要はありません。それらは、これらのギャップを無視するように特別に設計されています。

自動増分メカニズムは、上部のギャップ (最大の id 値を持ついくつかの製品を削除した後) またはすべてのギャップのいずれかを考慮するように設計されている可能性があります。しかし、スペースを節約するためではなく、時間を節約し、異なるトランザクションが誤って同じ ID を生成しないようにするために設計されたからではありません。

実際、PostgreSQL はそのSEQUENCEデータ型/SERIAL列 (MySQL auto_increment に相当するもの) を実装しており、トランザクションが数回インクリメントするシーケンスを要求したが、それらの ID を使用しなくなった場合、それらは決して使用されません。これは、トランザクションが誤って同じ ID を生成して使用する可能性を回避するようにも設計されています。

SMALLINTテーブルが固定長の 2 バイト整数を使用することを決定した場合、値がすべて 0 であるか最大値であるかは問題にならないため、スペースを節約することさえできません。INTEGER固定長の 4 バイト整数である法線を使用する場合。

UNSIGNED BIGINT8 バイトの整数を使用する場合、 8*8 ビット = 64 ビットを使用することを意味します。8 バイトの整数を使用すると、2^64 まで数えることができます。アプリケーションが何年にもわたって継続的に動作している場合でも、18446744070000000000 のような 20 桁の数字に達するべきではありません (それが一体何をする場合、既知の分子を数えているのですか?宇宙？）。

しかし、ID が数年で使い果たされるのではないかという懸念がある場合は、整数の代わりに UUID を使用する必要があります。

ウィキペディアは、「次の 100 年間、毎秒 10 億個の UUID を生成した後でのみ、複製が 1 つだけ作成される確率は約 50% になる」と述べています。

UUID はBINARY(16)、生のバイナリに変換したCHAR(32)かのように、ダッシュを取り除いたかのように、またはダッシュCHAR(36)を残したように保存できます。

16 バイトのうち = 128 ビットのデータ UUID は、122 のランダム ビットと 6 の検証ビットを使用し、いつ、どこで作成されたかに関する情報を使用して構築されます。つまり、さまざまなコンピューターで何十億もの UUID を作成しても安全であり、衝突の可能性は圧倒的に小さいということです (さまざまなマシンで自動インクリメントされた整数を生成するのとは対照的に)。

于 2012-06-26T21:41:01.767 に答える