データベーステーブルに主キーを挿入するときに、負の id またはゼロが悪い習慣と見なされるのはなぜですか?
場合によっては役立つと思いますが、その理由を決して言わない/知らないという事実にもかかわらず、人々はそれをお勧めしません.
それで、定義上、何らかの制限があるのか 、それとも問題がないのか 、それとも単なる慣例なのか、それについて実際に制限があるのなら、なぜその機能がブロックされていないのか疑問に思っていました.
データベーステーブルに主キーを挿入するときに、負の id またはゼロが悪い習慣と見なされるのはなぜですか?
場合によっては役立つと思いますが、その理由を決して言わない/知らないという事実にもかかわらず、人々はそれをお勧めしません.
それで、定義上、何らかの制限があるのか 、それとも問題がないのか 、それとも単なる慣例なのか、それについて実際に制限があるのなら、なぜその機能がブロックされていないのか疑問に思っていました.
明確にするために、この質問と回答は、自然キーではなく、代理キーに負の数を使用することに関するものです。
私の知る限り、それが悪い習慣であると考える理由は 3 つあります。
最初のものにはある程度の妥当性があります。負の ID 番号を使用する SQL の例や SO の回答は表示されません。(今日から変えます。)
2 番目と 3 番目は、プログラマーが予期しない動作を想定することが多いという点で、最初の結果の帰結です。(VBA を使用すると、2 つの日付を乗算して、おそらく平方日付で表される数値を返すことができることを思い出しました。)
番号 2 については、アプリケーション プログラマーが UI コードにサインインする余地を与えないことで、微妙なエラーが発生する可能性があります。
3 つ目は、ID 番号を返すコードを記述することです。単一の ID 番号を返すコードは、エラー コードとして -1 を返す場合があります。ただし、ほとんどの場合、-1 は有効な ID 番号です。(ほとんどのデータベースは、ID 番号を負でない整数の範囲に制限していません。)
この問題について議論しているサイトは 5,100 万以上あります。
私は@Mike Sherrillに同意します。NULL/空のフィールドまたは負のIDが真の値を決定する際に深刻な問題を引き起こすことはよくあることです。情報提供の目的はまったくなく、不正確な回答やデータベース自体への不信につながるだけです。
列にゼロ値、負の値を許可すると、データベースにまったく新しい程度の不確実性が導入されます。データベース内の NULL 値の誤った結果に対処するために、SQL プログラマーが推測を行う必要があります。