Каковы недостатки использования случайных ROWID в SQLite?

Question

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

Тем не менее, я был бы признателен за ответ об использовании вместо этого рандомизированных строк. Я планирую вставить одну фиктивную строку для всех моих таблиц с rowid = MAX_ROWID, чтобы каждая новая строка, вставленная в таблицы, получала случайные значения rowid - документированное поведение в SQLite3.

Спасибо!

Answer 1

Потенциальным решением было бы воспользоваться преимуществами алгоритма, используемого sqlite для определения следующего rowid.

То есть, как правило, идентификатор строки будет на 1 больше предыдущего, то есть до тех пор, пока не будет получено максимальное значение, тогда, пока AUTOINCREMENT не закодировано SQLite будет пытаться найти неиспользуемое / свободное значение .

Таким образом, если вы вставите строку с этим значением, последующие строки не будут последовательными.

Если на вставке не указан ROWID или указанный ROWID имеет значение NULL, тогда соответствующий ROWID создается автоматически. Обычный алгоритм - дать вновь созданной строке ROWID, который один больше, чем самый большой ROWID в таблице до вставки. Если таблица изначально пуста, затем используется ROWID, равный 1. Если самый большой ROWID равен максимально возможному целому числу (9223372036854775807), тогда ядро ​​базы данных начинает выбирать положительный кандидат ROWID в случайном порядке, пока не найдет тот, который не был ранее используемый. Если не найден неиспользованный ROWID после разумного количества при попытках операция вставки завершается с ошибкой SQLITE_FULL. Если нет отрицательные значения ROWID вставляются явно, затем автоматически сгенерированные значения ROWID всегда будут больше нуля. Автоинкремент SQLite

Например, рассмотрим следующее: -

DROP TABLE IF EXISTS randid;
CREATE TABLE IF NOT EXISTS randid (ID INTEGER PRIMARY KEY , data TEXT);

-- INSERT A ROW using the highest possible value for the ID 
INSERT INTO randid VALUES(9223372036854775807,'dummy'); -- <<<<<<<<<< THE BASIS OF THIS METHODOLOGY

-- insert some more data letting SQLite generate the ID
INSERT INTO randid (data) VALUES('a'),('b'),('c'),('d'),('a'),('b'),('c'),('d'),('a'),('b'),('c'),('d'),('a'),('b'),('c'),('d');

-- get the resultant data from the table
SELECT * FROM randid; 

Результат от 1-го забега: -

Результат от другого прогона: -

За исключением последней строки (которая была добавлена ​​первой), вы даже не можете легко определить порядок вставки.

Каковы недостатки использования случайных строк в SQLite?

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

Вы упомянули rowid , в приведенном выше примере используется псевдоним rowid , и, хотя он не скрыт как rowid , значение не будет иметь большого значения, если оно будет сделано видимым (почему вы? (это риторика)).

Однако один недостаток с rowid , который изначально можно было бы использовать таким же образом, состоит в том, что VACUUM перенумеровывает все rowids , если столбец rowid не иметь псевдоним, который отменяет случайность.

Answer 2

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

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