오라클에서 Postgres 로의 패키지 레벨 상수 변환

Question

데이터베이스에서 모든 비즈니스 로직을 가진 Postrges로 애플리케이션을 변환하는 방법을 검토 중입니다. 현재 약 200 개의 공개 상수 변수가있는 매우 큰 패키지가 있습니다. Postgres는 패키지 수준 변수를 지원하지 않으므로이를 변환하는 방법을 논의하고 있습니다. 두 가지 가능성이 있지만 어느 것이 더 좋을지에 대한 의견이 필요합니다. 둘 다 매우 좋지 않습니다. 둘 다 매우 좋지 않습니다.

1. 각 변수를 정적 값을 반환하는 함수로 변환하십시오. 이것은 가장 가능성이 높지만 매우 추한 것 같습니다.
2. 값에서 표를 만드십시오. 이것의 문제점은 주로 다른 패키지/기능에 의해 사용된다는 것입니다. 또한 유형이 혼합되어 있습니다 (숫자 대 varchars).

아이디어가 있으십니까?

Answer 1

옵션 1을 사용하면이 작업을 자동으로 수행하는 스크립트를 작성하기가 쉽고 패키지를 원래 정의에 최대한 가깝게 유지해야합니다.

Answer 2

두 가지 옵션을 혼합했습니다. 쿼리에서 사용하기 쉽게하는 기능에 의해 새로운 옵션 또는 수정을 추가하기 쉽게

create table package_options (option_name text, option_value text) 

및 반환 : 옵션을 테이블에 저장됩니다

이

create function get_option(text) returns text as 
$$ select option_value from package_options where option_name=$1 $$ 
language sql stable; 

도 get_int_option(text)가있을 수 있습니다, 값을 변환 int 등

또한 option_type 열과 몇 가지 제약 조건을 추가하여 유형 유효성을 검사 할 수 있습니다.

Answer 3

문제가 제시 한대로 성능 접근 방식과 인터페이스 방식을 취하고 있습니다.

데이터베이스 사용에 따라 옵션 2와 함께 사용하면 데이터베이스에 핫 스폿이 발생할 수 있습니다. 보다 극단적 인 시나리오 - 5000 명의 사용자가 시스템에 로그인하여 코드가 실행되고 package_options 테이블에 대해 코드가 선택됩니다. 특정 순간에 수천 명의 사용자가 해당 테이블을 때릴 수 있습니다.

PG가 동시성을 제대로 처리하지 못해 문제가 발생할 수 있으므로 테스트만으로 문제가 입증 될 수 있습니다. 확실하게보기 위해 테스트해야하지만이 접근법을 고려할 때 명심해야 할 점이 있습니다. 또한 옵션 1 시나리오를 테스트하여 관리 및 사용하기 쉬운 인터페이스 외에도 성능이 우수한 것을 확인합니다. 이것에 필요한 테스트를 고려하면 상대적으로 간단한 것이므로 테스트하지 않는 것이 좋습니다. 그러면 사용 시나리오에 대한 선택의 여지가없는 길에서 꼼짝 못할 필요가 없습니다.