데이터베이스에 큰 소수를 저장합니다

StackOverflow https://stackoverflow.com/questions/1907409

문제

이 문제는 나를 조금 이상하게 강타했습니다. 데이터베이스에서 소수 목록을 어떻게 표현할 수 있는지 궁금합니다. 나는 많은 양의 소수를 무서워하고 일관되게 저장할 수있는 단일 데이터 유형을 모릅니다. 내 관심사는 소수에 1000 자리의 자릿수를 포함하기 시작할 때 데이터베이스를 참조하기가 약간 어려울 수 있다는 것입니다. DB에서 큰 프라임 세트를 나타내는 방법이 있습니까? 나는 이것이 주제가 이전에 접근했다고 확신합니다.

어려운 문제 중 하나는 소수를 요인으로 분류 할 수 없다는 것입니다. 그들이이 문제가 훨씬 쉬울 수 있다면 훨씬 쉬울 것입니다.

도움이 되었습니까?

해결책

Primes를 숫자와 질문 중 하나로 저장하려면 "소수를 요인으로 분류 할 수 없습니다"라는 것을 중지하려면 다른 것이 있습니다. 시퀀스별로 주문한 숫자의 모듈러스 목록에 저장하십시오.

Small example:

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

목록은 다음과 같습니다.

81, 17, 83, 2

실제 응용 프로그램에서는 2^32 (32 비트 정수)의 계수로 분할하는 데 유용합니다. 특히 바이트 어레이로 저장된 처리 응용 프로그램의 소수 인 경우 특히.

DB의 스토리지 :

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;

다음 소수의 ID를 삽입 할 :

select seq_primes.nextval from dual;

지정된 ID로 소수 내용을 선택하십시오.

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

다른 팁

이진 데이터로 저장할 수 있습니다. 그들은 데이터베이스에서 바로 인간을 읽을 수 없지만 문제가되지 않아야합니다.

데이터베이스 (어느 것에 따라) 최대 38-39 자리의 숫자를 정확하게 저장할 수 있습니다. 그것은 당신을 합리적으로 멀리합니다.

그 외에도 데이터베이스 (특정 데이터베이스에 존재할 수있는 임의의 차수 모듈을 제외하고)에서 산술 작업을 수행하지 않을 것입니다. 그러나 숫자는 최대 수천 자리의 텍스트로 저장 될 수 있습니다. 그 외에도 클로브 타입 필드를 사용하여 수백만 자릿수를 저장할 수 있습니다.

또한 소수 시퀀스를 저장하고 해당 시퀀스의 공간 압축에 관심이있는 경우 정수가 아닌 한 숫자와 다음 숫자의 차이를 저장하여 시작할 수 있다는 것은 가치가 없습니다.

이것은 약간 비효율적이지만 문자열로 저장할 수 있습니다.

이 숫자와 함께 데이터베이스 측 계산을 사용하지 않으려면 이진 표현의 비트 시퀀스로 저장하십시오 (BLOB, VARBINARY 등.)

여기 내 2 센트 가치가 있습니다. 데이터베이스에 숫자로 저장하려면 데이터베이스가 처리 할 수있는 최대 정수 크기로 제한됩니다. 하나의 열에 소수가 있고 다른 열의 시퀀스 번호가있는 2 열 테이블을 원할 것입니다. 그런 다음 저장된 값을 빠르게 찾을 수 있도록 몇 가지 인덱스를 원할 것입니다.

그러나 당신은 정말로 그렇게하고 싶지 않습니다. 당신은 아직 당신이 아직도 정수 데이터 유형을 넘어서는 엄청난 (sp?) 프라임을 저장하고 싶습니다. 그리고 당신은 당신이 문자열에 반대한다고 말하면 이진 데이터라고 말합니다. 예, 네, 데이터베이스에 블로브에 보관할 수는 있지만 DBMS는 N-th 프라임을 찾거나 후보 정수의 원시를 확인하기 위해 어떤 종류의 시설을 제공 할 것인가?

적절한 파일 구조를 설계하는 방법은 무엇입니까? 이것은 약 5 분 후에 생각할 수있는 최고입니다.

  1. 카운터를 2로 설정하십시오.
  2. 첫 번째 소수를 나타내는 2 비트를 작성하십시오.
  3. 2 비트 프라임이 포함 된 섹션의 끝을 표시하려면 다시 작성하십시오.
  4. 카운터를 카운터+1으로 설정하십시오
  5. 3 비트 프라임을 순서대로 작성하십시오. (두 가지 : 5와 7이 있다고 생각합니다)
  6. 3 비트 프라임이 포함 된 섹션의 끝을 표시하기 위해 3 비트 프라임의 마지막 프라임을 다시 작성하십시오.
  7. 4로 돌아가서 Mutatis Mutandis를 수행하십시오.

마지막 N 비트 프라임을 두 번 쓰는 것에 대한 요점은 파일을 읽을 때 N- 비트 프라임이있는 파일의 일부의 끝을 식별하는 수단을 제공하는 것입니다.

파일을 작성할 때 아마도 다양한 지점에서 파일에 오프셋을 기록 할 수도 있습니다. 아마도 N- 비트 프라임이 포함 된 각 섹션의 시작 일 것입니다.

나는 이것이 효과가 있다고 생각하며, 최대 2^(당신이 표현할 수있는 가장 큰 서명되지 않은 정수)의 프라임을 처리 할 것입니다. 325467 비트 (SAY) 값을 큰 정수로 변환하기위한 코드를 찾는 것이 쉽다고 생각합니다.

물론,이 파일을 덩어리로 저장할 수는 있지만 왜 귀찮게하는지 잘 모르겠습니다.

그것은 모두 숫자로 무엇을하고 싶은지에 달려 있습니다. 저장하고 조회하는 경우 문자열을 사용하고 확인 제한 조건 / 도메인 데이터 타입을 사용하여 숫자임을 시행하십시오. 더 많은 컨트롤을 원한다면 PostgreSQL을 정의 할 수 있습니다. 사용자 정의 데이터 유형 그리고 기능. 예를 들어 인터페이스 할 수 있습니다 GMP 임의의 정밀 정수에 대한 올바른 순서 및 산술을 갖기위한 라이브러리. 이러한 라이브러리를 사용하면 확률 적 원시 테스트를 사용하여 숫자가 실제로 프라임인지 확인하는 체크 제약 조건을 구현할 수 있습니다.

실제 질문은 실제로 관계형 데이터베이스가 작업의 올바른 도구인지 여부입니다.

나는 당신이 얼룩을 사용하는 것이 가장 좋다고 생각합니다. 블로브에 데이터가 저장되는 방법은 의도 된 숫자 사용에 따라 다릅니다. 계산에 사용하려면 값을 다양한 순서 이진 값으로 저장하고 숫자 등으로 취급 할 수 있도록 클래스 또는 유형을 만들어야한다고 생각합니다. 그것들을 일련의 문자로 저장하면 충분할 것이며, 계산 가능한 값을 표시 할 수있는 것으로 변환 할 필요가 없어서 큰 값에 대해 시간이 많이 걸릴 수 있습니다.

공유하고 즐기십시오.

아마도 훌륭하지는 않지만 재귀적인 데이터 구조에 저장하면 어떻게 될까요? int, 지수 및 하부 비트 숫자에 대한 참조로 저장할 수 있습니다.

문자열 아이디어와 마찬가지로 메모리 고려 사항에는 그리 좋지 않을 것입니다. 쿼리의 재귀 특성으로 인해 쿼리 시간이 증가합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top