ネガティブキーは何に使用されますか?


12

標準のSQLデータベースを使用するのはやや新しい(現在は主にMySQLで動作している)私はまだこの使用法の多くを実行していません。

テーブルをインデックス付けする負の(またはむしろ署名された)キーを持つのはいつ、なぜ便利ですか?


5
最初に、フィードバックを残さずにダウン票を投じる人は誰でも、あなたは悲惨なことをしています。次に、この素​​晴らしい質問への答え。
jcolebrand

1
このテーマは興味深いです。私は個人的にこの概念を聞いたことがありません。この質問は決して否定されるべきではありません。このコンセプトを紹介してくれた私の+1。
RolandoMySQLDBA

回答:


13

主キーはすべて、レコードで最も重要な値であると判断した値です。そのキーが符号付きint、符号なしint、文字列、blob(実際には制限があります)、またはUUID(または今日の名前)であっても、それがキーであり、最も重要なこと。

キーに正の方向の数値のみを使用するように制限されていないため、符号付き整数は最大20億になり、符号なし整数は最大40億になると考えるのは理にかなっています。ただし、signed intを使用して、初期値を〜-20億に設定し、増分を1に設定しても問題はありません。20億件のレコードが記録された後、「ゼロ」にヒットし、その後20億件まで続きます。

テーブルに「負のキー」を含めることが役立つ理由については、「なぜテーブルにキーを入れるのが役立つのか」と同じ質問です。キーの「値」は、キーとしてのステータスには影響しません。キーは、キーはキーです。

重要なのは、キーが有効かどうかです。

ネガティブなキーを許可することが有用である理由について、いくつかの理由を提案できます。

販売システムで、正の販売注文番号と一致する負の販売注文番号として返品を表示したい場合、相関関係を簡単にします(これは単純で設計が不十分ですが、「スプレッドシート」の意味では機能します)。

ユーザーテーブルを作成し、負の数を持つものがシステム制御されていることを示す場合(SOはこのことをチャットフィードユーザーに対して行います)。

先に進むこともできますが、実際に、負の数が重要である唯一の理由は、あなたまたは私が重要性を割り当てるかどうかです。それ以外は、キーの価値がキー自体に影響を与える大きな理由はありません。


「ニッチ発生」ビットを編集しました。これは、経験不足による誤解である可能性が高いためです。興味深い読み物。キーの負の値がコーディングで何らかの形で有用である状況があると想像していました(つまり、特定のことを意味することを決定せずに)が、これは2つのグループに強力に分かれており、ドン余分なboolを使用したくない:p
Garet Claborn

1
@Garet〜だから、あなたは良い点を指摘します:「キーの値はコーディングで何らかの形で有用でした」と私はちょうどその方法で時々キーを使用しますが、それはデータベースの側面とは関係ありません データベースは倉庫です。一方、データを消費するアプリケーションは、値を重視します。しかし、はい、その+/-ブール値はきちんとしたトリックです、私はそれがちょうどそのような効果のために多くの時間を使用するのを見てきました。
jcolebrand

2
-1は、このような二重の目的値が悪い考え以外のものであることを暗示しているためです。あなたはintとboolが必要ですか?intとboolを使用します。
ジャックはtopanswers.xyz

1
@JackPDouglas人々にそうすることを奨励したことは覚えていませんが、フィールドとそのデータは2つの異なるものであることを暗示しています。少なくともあなたのダウンボートに関する建設的なフィードバックを提供してくれてありがとう。しかし、それはデータベース層の問題ではなくアプリケーションロジックの問題であるため、「ネガティブキーは何に使われるか」という概念に照らして何も意味がないとは言えない。アプリケーション層でそれらがどのように使用されるかを強調したかったのですが、データベース層ではそれらは重要ではありません。
jcolebrand

1
@JackPDouglas〜聞いたことがある非常によく知られたサイト(サイトのネットワーク)があるので、私はその特定の例を使用しました。それが有効であるため、それを軽disしたくありません。 "騙す"。このユーザーdba.stackexchange.com/users/-1/communityをチェックして、彼のIDを教えてください。ユーザーIDがプライマリ(および他の多くのテーブルでは外部)キーであることをほぼ保証できます。あなたにとって悪いアプリケーション設計だからといって、それが有効ではないという意味ではありません。しかし、これもdb設計ではなく、ドメイン設計です。確かに、dbロジックはそれをサポートしています
jcolebrand

10

ID列または自動番号列について説明している場合、値自体に意味はありません。(時々、ドラチェンスターンに言及されたSOのチャットユーザーのように、私は自分の前にやったことがあります)

ただし、通常、符号付き整数を使用している場合、範囲の半分が失われます。
参照:テーブルのフィールドが符号付きまたは符号なしの最大32ビット整数に近づいたらどうするか?

別の例:小規模なレプリケーションシナリオでは、あるサイトに負の値を使用し、別のサイトに正の値を使用すると、特定の行のソースに関する暗黙的な知識が得られます。


また、各サイトで入力された値を何らかの形で制約していることを確認してください。そうしないと、「暗黙の知識」が間違っていることが判明したときに恐ろしい混乱に陥ります。
ジャックは、topanswers.xyz

@JackPDouglas:間違ったサイトで値が生成されないようにするために、NOT FOR REPLICATIONを使用します
gbn

チェック制約とともに?また、NOT FOR REPLICATIONご存知のMySQL(または他の)類似物はありますか?
ジャックは、topanswers.xyz

@JackPDouglas:申し訳ありませんが、非SQL Serverについてはわかりません
gbn

8

すべてのデータベースシステムが符号なし整数型さえサポートしているわけではありません。MSSQLはサポートしていない整数型の1つです。これらの場合、整数キーフィールドでは負の値が可能なのは、単に型で可能なためです(この例に示すように、ルールまたはトリガーを使用してそれらをブロックできますが、そのようなルールを適用するオーバーヘッドをおそらく追加する必要はありません)すべてのインター/更新)。

データベースに関する限り、主キーの実際の値は、テーブル内で一意である限り重要ではありません。それに対して-42と42は、42と69と同じように2つの異なる数字にすぎません-意味は、コードによって負の値にのみ与えられるか、値の値には与えられません。

符号なし整数型をサポートしないことは、おそらく複雑さを減らすことに基づいた設計上の決定です。つまり、2つの異なる32ビット整数型に値を割り当てるときに範囲をチェックすることを心配しないようにします。0または1から始まる自動インクリメントフィールドで可能なインデックスの数を、符号なしのタイプで可能なものの半分(〜4e9ではなく〜2e9)に制限しますが、これは重要な問題になることはほとんどありません(必要な場合)特にそのような値が32ビットの値よりも効率的に処理される64ビットアーキテクチャを使用している場合は、おそらく64ビットタイプのキー値の多くはおそらくとにかく行きました)スペース上の理由で32ビットに固定するには、-2,147,483,647で増分を開始できます。


)tehehe;うん、私たちは前に地面を覆ったと思うdba.stackexchange.com/questions/983/...
jcolebrand

tinyintは符号なし(0 .. 255)です。私は通常、必然的にコードが暗黙のうちにそれを想定し、何とかならば奇妙なバグが負の値ゾッとを生じてしまうことに書き込まれるので、値は、非負であることを確認するために、整数の列にチェック制約を作成します。
エドエイビス
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.