Отрицательные целые индексы: они злые?

Question

У меня есть эта база данных, которую я разрабатываю.

Он должен содержать пару десятков таблиц с записями, которые мы предоставляем (куча значений по умолчанию), а также записи, которые пользователь может добавить. Чтобы пользователь не стрелял в ногу, необходимо, чтобы он не изменял записи по умолчанию.

Существует множество способов облегчить это, но мне нравится идея предоставления защищенных записей отрицательных целых индексов, при этом резервирование 0 в качестве недопустимого идентификатора записи и предоставление положительных целых индексов пользователям.

CREATE TABLE t1 (
    ixt1 integer AUTOINCREMENT, 
    d1 double, 
    CONSTRAINT pk_ixt1 PRIMARY KEY (ixt1), 
    CONSTRAINT ch_zero CHECK (ixt1 <> 0) 
); 

-2 | 171.3 <- canned record 
-1 | 100.0 <- canned record 
1 | 666.6 <- user record 

Причины этого кажется хорошим:

• он не использует значительно больше места

• это легко понять

• не требует много дополнительных таблиц для реализации

• «Выберите * из таблицы» получает все соответствующие записи, без дополнительной косвенности

• консервированных запись может расти в отрицательном направлении, и пользовательские записи могут расти в положительном направлении

Однако, Я относительно новичок в разработке баз данных. И после использования этого решения на некоторое время, я начинаю беспокоиться, что использование отрицательных индексов может быть плохим, потому что

• Отрицательные показатели могут не поддерживаться последовательно между различными СУБД, что делает его трудно писать код, является база данных агностика

• это может быть просто слишком легко ввернуть вещи вверх, вставляя что-то в RECID 0

• это может сделать его трудно использовать инструменты (например, БД сетки, возможно), что ожидать целочисленные индексы с неотрицательные значения.

И, возможно, есть и другие по-настоящему очевидные причины, которые сделают это очень плохой идеей.

Так какой окончательный ответ? Являются ли отрицательные целые индексы злыми?

Answer 1

Важнейшим недостатком этого является проблема «интеллектуального ключа».

Отрицательные целые числа отлично работают как ключ. Во всех базах данных.

Инструмент не требует значений положительного целочисленного индекса.

Относительно легко это испортить, потому что индекс имеет «правило», которое не очевидно, и никто не запомнит после того, как вы выиграли в лотерею и ушли.

Кроме того, когда вы изобретаете третий код состояния («предварительно консервированный» и «консервированный для клиента»), а также другие консервы, изобретенные продуктовой линейкой, «старые консервы до версии 3») вы обречены.

Проблема с «интеллектуальными ключами» заключается в том, что вы запрашиваете ключ для выполнения двух несвязанных заданий.

1. Это уникальный идентификатор записи. Это то, что должен быть ключ.

2. Вы также просите его предоставить статус, контроль и авторизацию для изменения свойств. К сожалению. Это чревато опасностью. Вы не можете расширить значение, потому что это один бит, зарытый в ключ.

Просто добавьте столбец с «принадлежащим». Если он принадлежит «магическому суперпользователю», то он не отображается пользователям. Используйте VIEW, чтобы убедиться в этом, если вы не можете доверять разработчикам приложений, чтобы обеспечить их соблюдение.

Если это принадлежит «магическому суперпользователю», то это данные по умолчанию и любые правила, применяемые к этой собственности.

Answer 2

Я работал над очень большой биллинговой системой. У нас была очень похожая проблема ... нужно отметить некоторые записи как «специальные». Клиенты имели десятки миллионов строк существующих данных в своих базах данных для затронутой таблицы, и было сочтено неприемлемым перенести все эти данные в новую структуру (например, добавить столбец).

Решение было принято, чтобы сделать то, что вы предлагаете.

Проблема в том, что вам нужно, чтобы каждый бит бизнес-логики знал (и помнил) особое значение отрицательных индексов и правильно относился к нему. Это довольно склонный к ошибкам (говорит по опыту).

Если у вас нет необычных обстоятельств, которые очень сильно говорят в пользу этого нетрадиционного подхода, я предлагаю вам придерживаться более традиционной дополнительной колонки. Это то, что большинство разработчиков используют и, следовательно, менее склонны вызывать ошибки. Хотелось бы, чтобы мы укусили пулю и добавили дополнительную колонку.

Answer 3

Это ваши данные, но я не думаю, что это хорошая идея. Значение «index», подобное этому, должно быть бессмысленным - не используйте знак или диапазон чисел или что-то другое, чтобы означать «что-то» или «что-то еще». Я думаю, что в конечном итоге вам будет гораздо лучше иметь столбец типа записи, который четко указывает, на какую запись вы смотрите. По моему опыту это гораздо лучший подход.

Удачи.