Чому SQL Server не підтримує тип даних без підпису?

83

Я спеціально думаю про без підпису int.

Ось практичний приклад: що ви робите, коли стовпець вашого посвідчення перевищує? Можна або перейти BigInt(8 байт пам’яті замість 4), або рефакторинг програми для підтримки від’ємних цілих чисел, і навіть створити власні правила, як зазначено у цій відповіді ; жоден із цих варіантів не є оптимальним.

UInt було б ідеальним рішенням, але SQL Server цього не пропонує (там, де MySQL).

Я розумію, що непідписані типи даних не є частиною стандарту SQL (SQL-2003), але все одно здаються мені марними.

У чому причина їх не включення (в SQL Server або в стандарт)?

— Ромгайн
джерело

11

Запитайте команду розробників SQL Server ..... також: чи справді ви збираєтеся максимально збільшити навіть 2 МІЛЯРДИ ІНТЕНТИФІКАЦІЇ ?? Справді?!?!?! Якщо у вас є понад 2 мільярди рядків, з чим би ви не мали справу, я впевнений, ви можете пошкодувати трохи місця на диску і використовувати BIGINT як ІДЕНТИЧНОСТЬ ....

— marc_s

6

Що ви маєте на увазі marc_s? Це лише вставка кожні 800 мс протягом 50 років поспіль, у ваших таблицях немає такої діяльності? :)

— Майк М.

21

@Mike M: Не всі ми працюємо над програмами Міккі Мауса ... ми використали 3 мільярди + бігінта менше ніж за 2 роки. Пік> 2000 рядків на секунду.

— gbn

5

@gbn Я не мав на увазі, що ніхто не мав такого навантаження. Однак, як уже було сказано, якщо у вас є> 2000 рядків на секунду, додатковий 2B не допоможе вашій справі.

— Mike M.

9

@Mike M та @marc_s, якщо я працював над системою з таблицею 2 мільярди рядків, я можу звернути увагу на марнотратне зберігання. Я можу звернути увагу на розмір сторінки індексу та на продуктивність сканування індексу. У таких умовах я хотів би не витрачати даремно простір.

— Romhein

64

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

— Джефф Хорнбі
джерело

3

Я думаю, це найближче, що ми можемо отримати до відповіді на це питання. Дякую.

— Romhein

8

Якщо "поширення типів" могло заощадити трохи місця / грошей, чому ви гадаєте, це могло бути злом.

— Самуель

1

Отримання рядків за їх значенням також буде повільнішим (тобто ORDER BY ABS(Id)), особливо якщо стовпець є кластерним первинним ключем. Наприклад, використання 32-розрядної мітки часу unix часто є зручним способом збрити 4 байти зі стандартного часу SQL.

— Groo

52

Для цього ви можете використати -2 147 483 648 як значення насіння.

Identity(-2147483648, 1)

— CFreitas
джерело

46

Я знайшов подібне запитання в Microsoft Office Dev Center.

У відповіді від Джима Хогга (менеджера програми) є деякі плюси та мінуси щодо додавання непідписаних int. Основним недоліком є те, що правила реалізації неявних перетворень типів стають кошмаром, щоб виправитись.

Запит закрито як "Не вдається виправити".

— Ентоні К
джерело

Посилання вже не працює, тому я не можу прочитати оригінальну відповідь. Але я вважаю, що проблема не в тому, що це кошмар; це те, що не існує стандарту, який би вказував, як це робити. Вони можуть робити те, що робить MySQL, наприклад (я не думаю, що інші СУБД підтримують UNSIGNED), але якщо інша СУБД додає підтримку знаків, вони можуть використовувати інші правила. Дизайн конверсії є важливою справою. JavaScript - це приклад того, що відбувається, коли до цього не ставляться серйозно.

— Федеріко Раззолі

Оновлене посилання - коментар Джима Хогга на форумі розробників MSSN Office.

— Ентоні К

1

Вони не підтримують ключове слово SIGNED і UNSIGNED, оскільки вони не є стандартними. У стандарті SQL усі числові типи підписані.

UNSIGNED (та SIGNED, що є за замовчуванням) - це розширення MySQL, які можуть бути корисними для зберігання вищих непідписаних чисел у однаковій кількості байтів та заборони негативних чисел.

— Федеріко Разцолі
джерело