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

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

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

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

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

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

• "select * from table" получает все соответствующие записи без дополнительного косвенного обращения

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

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

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

• Может быть, слишком просто все испортить, вставив что-то в recid 0

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

Удачи.