Для чого використовуються негативні ключі?

Дещо нове у використанні стандартних баз даних SQL (в даний час працюю з MySQL здебільшого), я ще не працював у багатьох випадках.

Коли і чому корисно мати негативні (а точніше підписані) ключі, що індексують таблицю?

Весь первинний ключ - це значення, яке ми визначили, це значення, яке є надзвичайно важливим у записі. Незалежно від того, чи є цей ключ підписаним int, непідписаним int, рядком, blob (насправді, є обмеження) або UUID (або якою б його назвою вона займається сьогодні), факт все ще означає, що це ключ, і що це річ надзвичайно важлива.

Оскільки ми не обмежуємося використовувати лише ключі, орієнтовані на позитивні, для цього є сенс вважати, що підписаний int складе лише ~ 2 мільярди, тоді як неподписаний int складе ~ 4 мільярди. Але немає нічого поганого в тому, щоб використовувати підписаний int, встановити початкове значення ~ -2 мільярда і встановити приріст одного. Після ~ 2 мільярдів записів ви наберете нуль, а потім продовжите ~ 2 мільярди.

Щодо того, чому було б корисно мати «негативні ключі» в таблиці, це те саме питання, що і «чому корисно мати ключі в таблиці». "Значення" ключа не впливає на його статус ключа. Ключ - ключ, ключ.

Важливо, якщо ключ дійсний.

Щодо того, чому було б корисно дозволити негативні ключі, я можу запропонувати деякі причини:

Що робити, якби ви хотіли вказати прибутки в системі продажів як негативні номери замовлень продажів, які відповідали позитивному номеру замовлення на продаж, тим самим полегшуючи співвідношення (це наївно та погано розроблено, але воно буде працювати в сенсі "електронних таблиць").

Що робити, якщо ви хотіли мати таблицю користувачів та вкажіть, що ті, хто має негативні цифри, контролювалися системою (ТАК це дуже важливо для користувачів каналу чату).

Я можу продовжувати, але насправді єдиною причиною, чому число, яке має негативне значення, є важливе значення, якщо ви чи я присвоюєте йому значення. Крім цього, немає великої причини, щоб значення ключа мала якесь відношення до самого ключа.

Якщо ми говоримо про стовпчики особи чи автономного числення, саме значення не повинно мати значення. (іноді це відбувається, як повідомляють користувачі чату SO, визначені drachenstern, що я робив раніше)

Однак, як правило, ви втратите половину свого діапазону, якщо використовуєте підписані цілі числа.
Див.: Що робити, коли поле в таблиці наближається до максимально підписаного чи непідписаного 32-бітного цілого числа?

Інший приклад: у невеликих сценаріях реплікації використання негативних значень для одного сайту та позитивних для іншого дає певні неявні знання про джерело будь-якого рядка.

Не всі системи баз даних навіть підтримують цілочисельні типи без підпису, MSSQL є одним із тих, хто цього не робить. У цих випадках від'ємні значення можливі в цілих ключових полях просто тому, що вони можливі в типі (ви можете використовувати правила або тригери для їх блокування, як показано в цьому прикладі , але, мабуть, не потрібно додавати накладні витрати на примусове застосування таких правил до кожен інтерс / оновлення).

Що стосується бази даних, то фактичне значення первинного ключа не має значення, поки воно унікальне в таблиці. Для нього -42 і 42 - це лише два різних числа однаково 42 та 69 - це означає, що ваш код буде наданий лише негативності чи значенню.

Непідтримка непідписаних цілочисельних типів, мабуть, є рішенням проекту, заснованим на зменшенні складності, тобто не хоче, щоб два різних 32-бітових цілочисельних типу не турбувалися про перевірку діапазонів при призначенні значень між ними. Це обмежує кількість можливих індексів у полі автоматичного збільшення, починаючи з 0 або 1 до половини, що було б можливим у непідписаному типі (~ 2e9, а не ~ 4e9), але це рідко є суттєвою проблемою (якщо вам, швидше за все, знадобиться ряд ключових значень такої величини ви, ймовірно, все-таки використовували для 64-бітного типу, особливо якщо використовуєте 64-бітну архітектуру, де такі значення обробляються не менш ефективно, ніж 32-розрядні), хоча якщо ви хочете, щоб весь діапазон і потреба були щоб дотримуватися 32-розрядної з космічних причин, ви можете почати приріст на -2,147,483,647.