98

私は特に無署名について考えていintます。

実用的な例を次に示します。ID列が最大になったときに何をしますか？実行するかBigInt（4ではなく8バイトのストレージ）、負の整数をサポートするようにアプリケーションをリファクタリングすることも、この回答に示されているように独自のルールを作成することもできます。これらのオプションはどちらも最適ではありません。

UInt理想的なソリューションですが、SQL Serverはそれを提供していません（MySQLが提供している場合）。

符号なしデータ型はSQL標準（SQL-2003）の一部ではないことを理解していますが、それでも私には無駄のように思えます。

これらを（SQL Serverまたは標準に）含めない理由は何ですか？

4

7 に答える 7

76

推測しなければならないのですが、彼らはタイプの急増を避けようとしていると言えます。一般的に言って、符号なし整数ができることは、符号付き整数ができないことは何もありません。2147483648から4294967296までの数値が必要な場合は、その数値も最終的に4294967296を超えるため、おそらく8バイト整数にする必要があります。

于 2010-12-15T16:08:32.847 に答える
73

そのために、シード値として-2,147,483,648を使用できます。

Identity(-2147483648, 1)
于 2012-01-09T15:05:11.147 に答える
54

Microsoft OfficeDevCenterで同様の質問を見つけました。

Jim Hogg（プログラムマネージャー）からの返信には、unsignedintを追加するための賛否両論があります。主な欠点は、暗黙の型変換を実装するためのルールが正しくなるための悪夢になることです。

リクエストは「修正されません」としてクローズされました。

于 2013-08-08T07:25:17.203 に答える
1

これらは標準ではないため、SIGNEDおよびUNSIGNEDキーワードをサポートしていません。SQL標準では、すべての数値タイプが署名されています。

UNSIGNED（およびデフォルトのSIGNED）は、MySQLの拡張機能であり、同じバイト数でより高い符号なしの数値を格納し、負の数を禁止するのに役立ちます。

于 2019-12-17T21:02:28.537 に答える
0

たとえば、32ビット（8バイト）のintを取り上げます。32ビット整数の範囲は-2^31から2^31-1です。割り当てた値を記録するのに31ビットかかり、値の符号を記録するのに1ビットしかかかりません。

したがって、あなたの質問に対する答えは「不要」です。割り当てたすべての値が正であっても、値ごとに1ビットしか無駄になりません。値ごとに1ビットのみを節約するための新しいデータ型を作成することは、ストレージスペースを最適化するための良い方法ではありません。

于 2021-04-06T03:59:18.210 に答える
0

最小IDID（-2147483648、1）を持つようにDBを設定します

次に、.net UInt64変数にロードするときに、2147483648を追加します。次に-2147483648は0になります-1000000000は1147483648になります

  • ただし、ほとんどの場合、内部キーはクライアントに公開されるべきではありません。通常、「ABCKey1」のような別のキーを使用します。

ただし、99％のシステムでデータ型が十分に大きいことに同意します。本当にもっと必要な場合は、GUIDを使用できますが、次の順次GUIDを使用しない限り、インデックスには問題があります。

于 2021-04-23T19:35:43.213 に答える
0

SQLServerで符号なしの数値が必要な場合があります。たとえば、2進値に相当するものを整数として格納する必要がある場合があります。この場合、32ビットのバイナリ値には、32ビットのintデータ型ではなく64ビットのbigintを使用する必要があります。

于 2021-12-27T14:14:46.770 に答える