Oracle 프로그램 개발 팁

오라클에는 많은 장점이 있지만 잘못 사용하면 그 강력한 장점을 발휘할 수 없습니다. 제가 오라클 개발 과정에서 쌓은 작은 경험을 여러분께 공유해 드립니다.

1. 데이터베이스 디자인에서 필드 사용

일부 테이블 디자인에는 기본적으로 표준이 된 몇 가지 일반적으로 사용되는 단락이 있습니다. 필드 이름은 다를 수 있지만 이러한 필드 추적입니다. 일반적으로 사용되는 필드는 다음과 같은 카테고리로 구분됩니다.

1.WHO 필드

이 필드는 누가 추가했는지 등 각 레코드 행의 작업 변경 정보를 기록하는 데 주로 사용됩니다. 행과 수정 등의 자세한 설명은 다음과 같습니다.

날짜

tr> 나. 작성자 어느 시스템이든 일반적으로 로그인 후 로그인한 사람의 정보가 데이터베이스의 특정 부분에 로그인하면 시스템 메모리에 기록됩니다. 테이블이 추가되면 이후 통계 및 감사를 위해 운영자의 ID 값이 동시에 테이블에 기록됩니다 II. 생성 시간 은 생성 시 시스템의 현재 시간이 기록되는 것과 유사합니다. 예를 들어 Oracle에서는 이 필드의 값을 가져옵니다. , 이 필드의 값으로 SYSDATE를 직접 사용할 수 있습니다. III. 마지막 수정자 기록이 생성된 후 수정될 수도 있습니다. 여기서는 추후 감사를 용이하게 하기 위해 수정된 사람의 기록이 필요합니다. 그런데 여기서 주의할 점은, 여기에는 마지막 수정 정보만 기록된다는 점입니다. 기록이 여러 번 수정된 경우 중간에 수정 내용이 추적되지 않습니다. 로그 기능을 사용해야 하는데 이 필드의 기능을 초과했습니다. IV. 마지막 수정 날짜 는 마지막 수정 날짜와 동시에 기록에 기록됩니다. 마찬가지로 마지막 수정 날짜가 마지막 수정 날짜로 기록되는 시간이기도 합니다. . 2． 상태 및 유효성 필드 일부 뉴스 콘텐츠에는 적시성이 관련된 경우가 많습니다. 즉, 뉴스는 특정 기간 내에만 외부 세계에 표시될 수 있으며 그 이후에는 허용되지 않습니다. 이 기간 동안 일부 콘텐츠에 문제가 있어 외부에서 일시적으로 차단해야 하는 경우 상태 필드를 사용할 수 있습니다.

字段名称	类型	说明
LAST_UPDATE_DATE	DATE	最后修改日期
LAST_UPDATED_BY	NUMBER(15)	最后修改人
CREATION_DATE	DATE	创建日期
CREATED_BY	NUMBER(15)	创建人

필드 이름

유형

설명

LAST_UPDATE_DATE

날짜

마지막 수정 날짜

LAST_UPDATED_BY

NUMBER(15)

최종 수정자

CREATION_DATE

생성 날짜

字段名称	类型	说明
STATUS	NUMBER	状态
START_DATE	DATE	有效开始日期
END_DATE	DATE	有效结束日期

CREATED_BY

NUMBER(15)

작성자

필드 이름	유형	설명
상태	숫자	상태
START_DATE	날짜	유효 시작일
END_DATE	날짜	유효한 종료일

나. 상태

이 필드는 일반적으로 숫자 형식으로 표현되며 0은 유효하지 않음을 의미하고 1은 유효함을 의미합니다. 물론 사용 시 이 두 값을 이스케이프하여 "유효함" 및 "유효하지 않음"으로 표시할 수 있습니다. . 저장 방법에 영향을 미치지 않습니다.

무효화는 삭제를 의미하지 않으며, 만료된 콘텐츠는 관리 프로그램에 의해 조정된 후 정상 상태로 복원될 수 있습니다.

Ⅱ. 유효한 시작 날짜

이 필드에 특정 값을 입력하면 해당 시간을 초과하는 경우에만 정보가 유효하며, 이 날짜 이전에는 해당 정보가 자동으로 유효하지 않은 것으로 처리됩니다. 이 필드를 공백으로 두면 이 조건 확인을 건너뛰어 처리해야 프로그램 유연성을 확보할 수 있습니다.

III. 유효기간 종료일

구체적인 의미는 위와 동일하며, 이 기간 이후에는 해당 콘텐츠가 무효 처리된다는 점만 다릅니다.

3． 논리적 삭제

데이터베이스 시스템의 삭제 방법에는 일반적으로 물리적 삭제와 논리적 삭제의 두 가지 방법이 있습니다. 소위 물리적 삭제는 데이터베이스에서 직접 삭제 및 기타 명령을 사용하여 실제로 데이터베이스에서 데이터를 삭제하는 것을 의미합니다. , 이러한 종류의 삭제는 일반 채널을 통해 데이터를 복구할 수 없습니다. 전체 데이터 양을 부분적으로 줄일 수는 있지만, 논리적 삭제는 데이터가 삭제되지 않지만 기록이 삭제되는 것을 의미합니다. 즉, 특정 필드에 값을 할당하면 레코드가 삭제되었음을 나타냅니다.

데이터가 실제로 데이터베이스에 여전히 존재하기 때문에 논리적 삭제의 처리 논리는 애플리케이션 자체에서만 사용됩니다.

관련 필드는 다음과 같습니다.

字段名称	类型	说明
DELETED	NUMBER	是否删除
DELETE_DATE	DATE	删除时间
DELETED_BY	NUMBER	删除人

필드 이름

유형

설명

삭제됨

NUMBER

삭제 여부

DELETE_DATE

날짜

시간 삭제

DELETED_BY

NUMBER

사용자 삭제

나. 삭제 플래그

이 필드에는 두 가지 값이 있습니다. 0은 정상, 1은 삭제를 의미합니다.

모든 쿼리문은 삭제 표시를 한 후 판단 조건에 삭제=0 조건도 추가해야 합니다. 그렇지 않으면 중대한 실수가 발생합니다.

Ⅱ. 삭제 시간

은 삭제 플래그와 함께 사용되어 삭제 시간을 나타냅니다. 현재 서버 시간을 사용하고 sysdate로 채울 수 있습니다.

III. 삭제자

마지막 수정자와 마찬가지로 삭제의 특정 연산자를 기록해야 합니다

삭제는 플래그 비트 방식과 다릅니다. 데이터를 표시할 수 없으므로 백그라운드 관리 담당자가 관리 프로그램을 통해서도 상태 조정이 가능하지만, 삭제 확인 후에는 해당 기록이 전체 애플리케이션에 대해 존재하지 않는 것으로 이해해야 합니다.

4． 자동 증가 필드

소위 자동 증가 필드는 사용에 따라 자동으로 추가될 수 있는 필드를 말합니다.

이 필드의 값은 일반적으로 명확한 의미가 없으며 고유 식별자로만 사용됩니다. 이 필드는 일반적으로 기본 키로 설정됩니다.

애플리케이션이 Oracle만을 대상으로 하고 데이터베이스 독립성을 고려하지 않는 경우 시퀀스가 ​​최선의 선택입니다. 이전에 MSSQL 등 다른 데이터베이스를 사용했던 사람들에게 Oracle을 사용하는 것은 단순히 자동 증가 필드를 만드는 데 많은 노력이 필요하지만 이로 인해 다른 데이터베이스에서도 문제가 발생합니다. 예를 들어, 주문 시스템에는 주문 헤더와 주문 라인이 모두 있는 것과 비교하면 일반적으로 주문 헤더가 먼저 삽입된 다음 MSSQL과 같은 데이터베이스의 자동 증가 필드가 삽입됩니다. 구체적인 정보는 삽입 후에만 알 수 있습니다. ID 값은 무엇입니까? 가장 중요한 것은 시퀀스 효과가 매우 높으며 성능 문제에 대해 걱정할 필요가 없다는 것입니다.

5． 유연한 필드

데이터베이스 테이블 구조를 설계할 때 시스템을 사용하면 일반적으로 필드를 추가해야 하기 때문에 몇 가지 여유 필드를 따로 두는 것이 가장 좋습니다. 예약된 필드의 장점은 DDL 작업이 필요하지 않은 경우에만 활성화할 수 있다는 것입니다. 또한, 일반 DDL 작업으로 인해 계단식으로 연결된 VIEW/PACKAGE 및 기타 프로그램이 실패할 위험이 매우 낮습니다. 예약된 필드 탄력적 필드를 추가하면 이 문제가 발생하지 않습니다.

예약된 필드도 유형에 따라 문자열 유형, 숫자 유형, 날짜 유형의 세 가지 유형으로 나눌 수 있으며 각 유형별로 10개의 필드를 예약하거나 필요에 따라 다음 스타일을 사용할 수 있습니다. :

NUMBER_ATTRIBUTE1

STRING_ATTRIBUTE1

DATE_ATTRIBUTE1

탄력적 필드가 활성화되지 않으면 너무 많은 저장 공간을 차지합니까? 대답은 '아니요'입니다. 왜냐하면 이 대용량 데이터베이스의 구조에서는 필드가 실제로 사용될 때만 실제 공간을 차지하게 되기 때문입니다. 그렇지 않으면 단지 "설명"일 뿐 실제 공간을 차지하지 않으므로 공간 낭비가 발생하지 않습니다.

6． 분할 필드

이것은 필드 유형이 아니지만 테이블 설계 중 저장을 위해 여러 개의 작은 테이블로 적절하게 분할할 수 있는 큰 테이블을 의미합니다. 예를 들어 사용자 테이블에는 로그인 이름, 비밀번호, 이름, 생일 및 일련의 필드가 포함된 경우에는 포함된 구성원 속성 수가 수백 개에 달할 수 있습니다.

데이터의 양이 적을 경우에는 어떤 스토리지를 사용해도 성능 문제가 없으나, 데이터의 양이 상대적으로 클 경우에는 성능 문제를 고려해야 합니다. 인덱스가 적당하다면 데이터 양이 아무리 많아도 일반적인 쿼리 속도는 그리 느리지 않습니다. 그러나 일부 특수한 상황에서는 인덱스를 사용할 수 없는 경우 FTS(소위 전체 테이블 스캔)가 수행됩니다. 그런 다음 작은 테이블을 스캔하는 것과 큰 테이블을 스캔하는 데 걸리는 시간이 완전히 다르기 때문에 큰 테이블을 별도로 저장하고 일반적으로 사용되는 여러 필드를 별도로 추출하는 것이 좋습니다. 그래야 전체 테이블을 스캔하더라도 효율성을 높일 수 있습니다. 더 잘 통제될 수 있습니다.

사용시 메인 테이블과 서브 테이블에 인덱스가 있는 한 이를 결합하여 쿼리하는 것은 기본적으로는 실제 대형 테이블과 동일하지만 성능은 확실히 실제 대형 테이블에 비해 조금 느립니다. , 하지만 다른 한편으로는 성능 향상에 비하면 그만한 가치가 있습니다.

현재 일부 대형 시스템에서는 이 분할 방식을 채택하고 있습니다

2. 뷰의 합리적인 사용

뷰는 기본 테이블을 표현한 것으로 물리적으로 저장되지 않습니다. 데이터만 저장됩니다. 필요할 때 기본 테이블에서 호출되므로 쉽게 사용할 수 있도록 SQL을 캡슐화하는 도구로 이해할 수 있습니다.

뷰에는 많은 장점이 있습니다.

1. 편의성

쿼리가 복잡하면 프로그램에서 참조하기가 매우 불편합니다. 특히 이 SQL이 프로그램에서 반복적으로 호출되면 프로그램이 매우 비대해집니다. 전체 프로그램을 매우 신선하고 깨끗하게 보이게 만듭니다.

2． 유연성

여러 프로그램에서 테이블을 참조하는 경우 테이블의 구조가 변경되면 모든 프로그램에서 해당 조정을 수행해야 하며 작업량이 매우 큽니다. 보기를 올바르게 수정해야 하며 모든 프로그램에는 문제가 없습니다.

3． 보안

뷰는 기본 테이블의 제한된 수의 필드만 포함할 수 있으므로 권한이 공개되면 뷰를 사용하는 사용자는 기본 테이블의 다른 기밀 필드를 볼 수 있습니다.

뷰에는 장점이 많습니다. 실제 작업에서는 뷰를 더 많이 활용하는 것이 좋습니다.

3. PACKAGE

PACKAGE는 변수, 함수, 저장 프로시저를 하나의 패키지에 담을 수 있고, 모든 공용 변수를 패키지 전체에서 공유할 수 있는 것이 특징입니다. , 이곳이 가장 편리한 곳입니다.

패키지의 또 다른 특징은 외부 인터페이스가 더욱 단순해진다는 것입니다. 패키지 내부가 아무리 복잡하더라도 제한된 인터페이스만 외부 세계에 개방하면 됩니다.

패키지의 이러한 특성은 모든 문서에서 찾을 수 있습니다. 여기서는 aspx 프로그램이 oracle을 참조할 때 한 가지만 강조하겠습니다. 패키지의 경우 시스템 캐시로 인해 패키지의 유효하지 않은 상태가 기록됩니다. 패키지 상태가 유효하지 않음에서 유효로 재컴파일되면 IIS 캐시 기록의 상태가 자동으로 업데이트되지 않을 수 있습니다. 여전히 유효하지 않은 것으로 처리되어 시스템 오류가 발생합니다. 이러한 오류를 방지하기 위해 저는 주로 패키지에 STATUS라는 공용 함수를 추가하는데, 이 함수는 단순히 숫자 1을 반환합니다. 패키지의 다른 함수를 호출하기 전에 이 함수를 호출하여 패키지의 현재 상태를 확인합니다. 1이 올바르게 반환되면 후속 작업을 계속할 수 있습니다. 반환이 비어 있으면 현재 패키지에 문제가 있음을 의미하며 사용자에게 이를 처리하라는 메시지를 표시하는 상호 작용이 있을 수 있습니다. 트랜잭션 처리에 여러 패키지의 조정이 필요한 경우 이전 패키지가 성공적으로 처리되었으나 이후 패키지가 통과되지 못하는 경우 트랜잭션이 불완전하게 처리될 수 있으므로 매우 고통스럽습니다. 따라서 상태를 확인하는 것이 가장 필요합니다. 모든 패키지를 미리 확인하고 가능한 모든 위험을 미리 제거하세요.

4. 인덱스

인덱스의 역할은 매우 명확하여 검사 속도를 크게 향상시킬 수 있으며, 특히 대규모 테이블의 경우 인덱스가 없는 경우 전체 테이블 스캔이 필요합니다. 이는 시간이 많이 소요되는 작업이므로 프로세스 속도를 높이려면 해당 인덱스를 생성해야 합니다.

그러나 때때로 인덱스는 많은 수의 삽입이나 수정 및 삭제 작업과 같은 부정적인 영향을 미칠 수 있습니다. 모든 작은 작업이 동시에 인덱스를 수정하게 되어 효율성이 크게 떨어지기 때문입니다. DML 작업이 많기 때문에 DML 작업을 많이 수행하기 전에 먼저 인덱스를 삭제하고 작업이 완료된 후 인덱스를 다시 설정하는 것이 전체 시간 측면에서 많은 시간을 절약할 수 있는 방법입니다.

Oracle 프로그램 개발 팁과 관련된 더 많은 기사를 보려면 PHP 중국어 웹사이트를 주목하세요!