Хранение больших простых чисел в базе данных

эта проблема показалась мне немного странной. Мне любопытно, как вы можете представить список простых чисел в базе данных. Я не знаю ни одного типа данных, который мог бы acuratly и последовательно хранить большое количество простых чисел. Меня беспокоит то, что когда простые числа начинают содержать 1000 цифр, может быть немного сложно ссылаться на базу данных. Есть ли способ представить большой набор простых чисел в БД? Я совершенно уверен, что эта тема была подходили раньше.

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

7
database mysql oracle postgresql primes

9 ответов

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

маленький пример:

2831781 == 2*100^3 + 83*100^2 + 17*100^1 + 81*100^0

список:

81, 17, 83, 2

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

хранение в БД:

create table PRIMES
(
  PRIME_ID         NUMBER not null,
  PART_ORDER       NUMBER(20) not null,
  PRIME_PART_VALUE NUMBER not null
);

alter table PRIMES 
add constraint PRIMES_PK primary key (PRIME_ID, PART_ORDER) using index;

вставить, например, выше (например, только 1647):

insert into primes(PRIME_ID, PART_ORDER, PRIME_PART_VALUE) values (1647, 0, 81);
insert into primes(PRIME_ID, PART_ORDER, PRIME_PART_VALUE) values (1647, 1, 17);
insert into primes(PRIME_ID, PART_ORDER, PRIME_PART_VALUE) values (1647, 2, 83);
insert into primes(PRIME_ID, PART_ORDER, PRIME_PART_VALUE) values (1647, 3, 82);

prime_id значение может быть присвоено из последовательности oracle ...

create sequence seq_primes start with 1 increment by 1;

получить идентификатор следующего простого числа для вставки:

select seq_primes.nextval from dual;

выберите содержимое простого номера с указанным идентификатором:

select PART_ORDER, PRIME_PART_VALUE 
from primes where prime_id = 1647 
order by part_order
9

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

6

базы данных (в зависимости от которых) могут регулярно хранить номера до 38-39 цифр точно. Это достаточно далеко.

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

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

5

Это немного неэффективно, но вы можете хранить их как строки.

4

Если вы не собираетесь использовать вычисления на стороне базы данных с этими числами, просто сохраните их как битовые последовательности их двоичного представления (BLOB, VARBINARY etc.)

3

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

но вы действительно не хотите этого делать, не так ли, вы хотите сохранить humongous (sp?) простые числа за пределами любого целочисленного типа данных ты хоть еще. И вы говорите, что вы не любите строки, поэтому для вас это двоичные данные. (И для меня тоже.) Да, вы можете хранить их в BLOB в базе данных, но какие средства предложит вам СУБД для поиска n-го простого или проверки правильности целого числа-кандидата ?

Как создать подходящую файловую структуру ? Это лучшее, что я мог придумать примерно через 5 минут думаю:

  1. установите счетчик на 2.
  2. напишите два бита, которые представляют собой первое простое число.
  3. напишите их снова, чтобы отметить конец раздела, содержащего 2-битные простые числа.
  4. установите счетчик на счетчик+1
  5. напишите 3-битные простые числа по порядку. (Я думаю, что есть два: 5 и 7)
  6. снова запишите последнее из 3-битных простых чисел, чтобы отметить конец раздела, содержащего 3-битные простые числа.
  7. вернуться к 4 и продолжить mutatis мутандис.

смысл написания последнего N-битного простого дважды состоит в том, чтобы предоставить вам средство для идентификации конца части файла с N-битными простыми числами в нем, когда вы приходите читать файл.

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

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

конечно, вы можете сохранить этот файл как BLOB, но я не уверен, зачем вам беспокоиться.

3

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

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

1

Я думаю, вам лучше использовать BLOB. Как данные хранятся в вашем BLOB, зависит от вашего предполагаемого использования чисел. Если вы хотите использовать их в вычислениях, я думаю, вам нужно создать класс или тип для хранения значений как некоторого разнообразия упорядоченных двоичных значений и позволить им рассматриваться как числа и т. д. Если вам просто нужно отобразить их, то сохранение их в виде последовательности символов будет достаточным и устранит необходимость преобразования ваших вычисляемых значений в что-то displayable, которое может быть очень трудоемким для больших значений.

поделиться и наслаждаться.

0

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

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

0