테이블. 기본 키와 생성기

NOTICE: This document is the chapter from the book “The InterBase World” which was written by Alexey Kovyazin and Serg Vostrikov.

InterBase는 관계형 DBMS입니다. 즉, InterBase의 모든 데이터는 테이블로 저장됩니다. SQL 관점에서 구현된 테이블은 종이에 손으로 그리거나 Microsoft Excel과 같은 프로그램에서 만들 수 있는 일반적인 테이블과 매우 유사합니다. InterBase의 테이블에는 데이터가 배치되는 열과 행이 있습니다. 테이블은 반드시 하나의 데이터베이스 내에서 고유한 이름을 가져야 합니다. 테이블은 데이터베이스에서 정보의 주요 저장소이므로 테이블을 만들 때 매우 신중해야 합니다.

관계형 데이터베이스에서 테이블을 만드는 방법을 설명하는 규칙이 있으며, 이는 실제 세계의 데이터를 반영하면서도 데이터베이스에서 정보를 효율적으로 저장할 수 있게 해줍니다. “올바른” 데이터베이스를 설계하기 위해 이러한 규칙을 적용하는 과정을 정규화라고 합니다. 우리는 “올바른"이라는 단어를 의도적으로 인용했습니다. 왜냐하면 “정규화된 데이터베이스"와 “최적화된 데이터베이스"는 동의어가 아니기 때문입니다. 정규화 규칙을 무조건적으로 따를 필요는 없습니다. 항상 주어진 문제의 사양에 맞게 조정하십시오.

데이터베이스의 테이블 정규화는 책 [14.에서 자세히 다루어지므로, 우리는 다룰 수 없는 것을 다루려고 하지 않고 논의 주제인 InterBase 테이블로 돌아가겠습니다. 테이블을 만들 수 있게 해주는 DDL(DDL - Data Definition Language, 자세한 내용은 용어집 참조) 문장의 구문을 살펴보겠습니다:

CREATE TABLE table [EXTERNAL [FILE] “”] ( [, | …]);

여기서 table은 생성되는 테이블의 이름이고, - 생성되는 테이블의 열(때로는 필드라고도 함)에 대한 설명입니다. 옵션 table [EXTERNAL [FILE] “”]은 공유 데이터베이스 파일이 아닌 이름이 인 별도의 파일에 저장되는 소위 외부 테이블이 생성된다는 것을 의미합니다. 보시다시피 모든 것이 간단합니다. 테이블 이름과 포함된 열을 정의합니다. 이제 열을 정의하는 방법을 자세히 살펴보겠습니다. 열 생성 구문은 다음 DDL 문장으로 설명됩니다:

= col { datatype | COMPUTED [BY] (< expr>) | domain}

[DEFAULT { literal | NULL | USER}]

[NOT NULL] [ ]

[COLLATE collation]

이것은 상당히 큰 정의이지만, 열 정의에서 필수적인 문장은 일부에 불과합니다. 테이블의 모든 열은 테이블 내에서 고유한 이름과 함께 datatype 문장으로 정의된 데이터 유형, 또는 열 값 계산을 위한 표현식(계산 열의 경우), 또는 도메인(아래 참조)으로 정의된 domain을 가져야 합니다. 데이터 유형은 “데이터 유형” 장에서 다루었으므로 테이블 생성 SQL 표현식이 어떻게 구성되는지 쉽게 이해할 수 있습니다.

이전에 “데이터베이스 만들기” 장에서 만든 FIRSTBASE.gdb 데이터베이스에 연결하여 실제로 테이블 작업을 해보겠습니다. 테이블 생성, 삭제 및 업데이트와 관련하여 “InterBase 관리자 및 개발자 도구” 응용 프로그램에 나열된 InterBase 관리 도구 중 하나와 모든 InterBase 클론 공급 세트의 표준 유틸리티 isql.exe가 적합합니다.

다음은 TABLE_EXAMPLE이라는 간단한 테이블로, 다양한 유형의 3개 필드를 포함하는 예입니다:

CREATE TABLE Table_example ( ID INTEGER, NAME VARCHAR(80), PRICE_1 DOUBLE PRECISION);

이 테이블은 데이터베이스 개발 과정에서 가장 자주 발생하는 경우를 보여줍니다. 그러나 필드를 정의하는 다른 방법도 있습니다. 예를 들어 도메인을 사용하여 필드 유형을 설정할 수 있습니다. 도메인은 특정 유형 매개변수 조합을 편리하게 적용하기 위해 사용자가 정의한 유형입니다. 예를 들어 식별자 필드를 지정하기 위해 D_ID 도메인을 정의할 수 있습니다. 도메인을 정의한 후 필드 유형을 설정하는 데 사용할 수 있습니다:

CREATE DOMAIN D_ID AS INTEGER; CREATE TABLE Тable_example ( ID D_ID, NAME VARCHAR(80), PRICE_1 DOUBLE PRECISION);

ID 필드는 D_ID 도메인에 의해 정의된 유형을 갖게 됩니다. 따라서 도메인에서 필드 유형, 필요한 검사 및 제약 조건을 정의하면 이 도메인을 동일한 기능의 필드를 만드는 데 여러 번 적용할 수 있습니다. 예를 들어, 변수 유형 정의를 복사하는 지루하고 오류가 발생하기 쉬운 작업 없이 통화 필드를 정의할 수 있습니다. 테이블에서 열을 설정하는 세 번째 방법은 계산 열(COMPUTED BY)로 정의하고 값이 계산될 조건을 지정하는 것입니다. 예를 들어, 테이블에 PRICE_1 필드 값의 10%를 계산하는 열을 갖고 싶을 수 있습니다. 이 경우 다음 명령을 작성해야 합니다:

CREATE TABLE Тable_example ( ID INTEGER, NAME VARCHAR(80), PRICE_1 DOUBLE PRECISION, PRICE_10 COMPUTED BY (PRICE_1.0.1));

하지만 PRICE_1 필드에 데이터를 삽입하자마자 PRICE_10 필드에 이 필드 값의 10분의 1이 생길 것이라고 생각하지 마십시오. 아니요, 여기서 과정은 더 복잡합니다. 실제로 필요한 10분의 1은 PRICE_10 필드를 참조할 때만 얻을 수 있습니다. 예를 들어 이 테이블에 대한 SELECT 쿼리를 실행할 때입니다. 즉, 계산 필드에는 데이터가 저장되지 않으며, 필드와 연결된 표현식의 계산이 수행되고 결과가 쿼리 응답으로 생성됩니다.

이제 테이블에서 필드를 지정하는 3가지 주요 방법을 살펴보았습니다. 이제 열을 만들 때 설정할 수 있는 옵션을 자세히 살펴보겠습니다. 옵션 [DEFAULT {literal | NULL | USER}] - 열의 기본값을 설정할 수 있습니다. 자동 데이터 채우기에 매우 편리합니다. 기본값을 설정하는 방법은 3가지가 있습니다. 첫 번째는 literal로 지정되며 텍스트 상수, 숫자 또는 날짜로 기본값을 설정할 수 있습니다. 예를 들어 텍스트 기본값으로 열을 만드는 다음 표현식을 생성할 수 있습니다: NAME VARCHAR(80) DEFAULT ‘Василий Станиславович’

따라서 테이블에 삽입된 모든 필드는 기본값을 취하게 됩니다. 즉, NAME 필드에 다른 값이 정의되지 않은 경우 ‘Vasily Stanislavovich’ 문자열이 나타납니다. 기본값을 설정하는 두 번째 방법은 열 정의에 DEFAULT NULL을 지정하는 것입니다. 새로 생성된 레코드에서 이 열의 값은 다른 값이 명시적으로 설정되지 않은 경우 NULL이 됩니다. 예:

PRICE_1 DOUBLE PRECISION DEFAULT NULL

기본값을 설정하는 세 번째 방법은 열 정의에 DEFAULT USER를 지정하는 것입니다. 새로 생성된 레코드에서 이 필드에는 현재 사용자의 이름, 즉 InterBase에 연결하여 이 삽입을 실행한 사용자의 이름이 포함됩니다(사용자에 대한 자세한 내용은 “InterBase의 보안: 사용자, 기능 및 권한” 장(4부) 참조). 일부 필드의 경우 필드에 비어 있지 않은 값이 있어야 하는 것이 중요합니다. 예를 들어 문제 사양에 따라 비어 있을 수 없는 필드입니다. 필드가 정의된 값을 가져야 한다는 제약 조건을 데이터베이스 수준에서 설정하려면 열 설명에 다음을 추가해야 합니다:

NAME VARCHAR(80) NOT NULL

따라서 NULL 값을 저장할 수 없는 필드가 생성됩니다. 일반적으로 NOT NULL 제약 조건은 이 필드에 올바른 값을 확실히 할당하는 DEFAULT 옵션과 결합됩니다. 그러나 NOT NULL 제약 조건만으로는 충분하지 않은 경우가 많습니다. 예를 들어 데이터베이스에 가격을 저장하는 경우 가격이 음수 값을 취할 수 없다는 것은 분명합니다(물건을 구매할 때 추가 비용을 받는다면 좋겠지만). 서버가 데이터베이스에 삽입된 가격 값을 양수 조건으로 확인하게 하려면 열을 다음과 같이 정의해야 합니다:

PRICE_1 DOUBLE PRECISION CHECK (PRICE_1>0)

PRICE_1 열에 삽입된 값은 양수 조건으로 확인됩니다. 다양한 일관된 옵션을 결합할 수 있으며, 예를 들어 비어 있지 않은 값과 양수 확인을 동시에 설정할 수 있습니다:

PRICE_1 DOUBLE PRECISION NOT NULL CHECK (PRICE_1>0)

컬럼을 생성할 때 일부 옵션은 서로 결합할 수 없습니다. 예를 들어 기본적으로 NULL을 허용하면서 동시에 비어 있지 않은 값 제약 조건을 설정하는 것은 불가능합니다. 제약 조건(check)은 데이터베이스의 데이터 관리에 유용한 여러 기능을 수행할 수 있다는 점을 표시해야 합니다. 이들의 사용에 대해서는 “데이터베이스 제약 조건” 장에서 자세히 살펴보겠습니다.

지금까지 다양한 옵션을 가진 테이블과 필드를 생성하는 방법을 살펴보았습니다. 그러나 이미 존재하는 테이블을 변경해야 하는 경우도 있습니다. 물론 테이블을 완전히 다시 생성할 수도 있습니다. 먼저 테이블 삭제 명령을 실행한 다음 다시 생성해야 합니다. 예를 들어:

DROP TABLE Table_example; CREATE TABLE Table_example(ID NUMERIC(15,2);

하지만 이러한 방식의 테이블 변경에는 상당한 단점이 있습니다. DROP 명령으로 테이블을 삭제하면 테이블에 포함된 모든 데이터가 삭제되며, 데이터를 잃지 않으려면 임시 테이블에 복사해야 합니다. 이는 상당히 번거로운 작업입니다. 따라서 테이블 구조를 쉽게 변경할 수 있는 ALTER TABLE 명령이 있으며, 이를 통해 새 필드를 추가하고, 기존 필드를 삭제하며, 참조 무결성 제약 조건을 추가/삭제할 수 있습니다.

예를 들어, 사람의 부칭(아버지 이름) 데이터를 저장하기 위한 테이블에 열을 하나 더 추가하려고 합니다:

ALTER TABLE Table_example ADD Patronimic VARCHAR(80);

이 명령을 실행한 후 테이블 Table_example에는 Patronimic이라는 이름과 VARCHAR(80) 유형의 새 열이 생깁니다. 테이블에서 NAME이라는 열을 삭제하려면 다음을 실행해야 합니다:

ALTER TABLE Table_example DROP Name;

ALTER TABLE 문의 전체 구문은 [1]에서 확인할 수 있습니다. 이는 매우 유용한 명령이며, 우리는 자주 사용할 것입니다.

그렇다면 컬럼을 수정해야 하는 경우는 어떻게 해야 할까요? 예를 들어, 이름을 저장할 때 NAME보다 HUMAN_NAME 필드를 사용하는 것이 더 낫다고 결정했다고 가정해 보겠습니다. 이 경우 ALTER TABLE을 적용할 수 있습니다:

ALTER TABLE Table_example ALTER COLUMN NAME TO HUMAN_NAME;

필드의 유형을 변경하기로 결정한 경우, 예를 들어 필드에 저장되는 문자 수를 늘리려면 ALTER DOMAIN 문을 사용하여 이 필드의 도메인을 변경해야 합니다(위의 “데이터 유형” 장 참조).

지금까지 InterBase에서 테이블의 생성과 수정을 살펴보았습니다. 이제 데이터베이스 이론에 대해 조금 더 깊이 들어갈 때입니다. 이미 말했듯이 InterBase는 관계형 데이터베이스입니다. 또한 이는 테이블의 모든 레코드가 다른 레코드와 구별될 수 있는 특성을 가져야 함을 의미합니다. 고유 키의 특별한 메커니즘이 이 목적을 위해 사용됩니다.

테이블의 기본 키

물론 키가 전혀 포함되지 않은 테이블을 생성할 수도 있습니다. 이를 금지하는 것은 아닙니다. 그러나 앞서 말했듯이 효율적인 데이터베이스 생성은 정규화 규칙을 준수하지 않고는 불가능합니다. 키의 존재는 정규화의 가장 중요한 요소입니다. 따라서 데이터베이스의 이론과 정규화를 다루는 것이 목적은 아니지만, 키의 정의를 소개하고 InterBase에서의 기능을 검토해야 합니다. 단계별로 진행하며 가장 일반적인 키 유형인 기본 키부터 시작하겠습니다.

그렇다면 기본 키란 무엇일까요? 테이블 내에서 레코드를 고유하게 식별하는 하나 이상의 필드입니다. 어렵게 들리지만 실제로는 매우 간단합니다. 일반적인 테이블, 예를 들어 회계 시트를 상상해 보세요. 가장 첫 번째 열은 무엇일까요? 맞습니다, 일련 번호 - 1, 2, 3… 이 번호는 테이블 내의 고유한 행을 나타내며, 이 번호만 알면 테이블에서 해당 행을 찾을 수 있습니다. 이 예에서 이것이 기본 키가 됩니다. 관계형 데이터베이스의 압도적 다수의 테이블은 반드시 기본 키(PK - Primary key의 약어)를 가집니다. 테이블 생성 시 기본 키를 만드는 것이 일반적인 지침입니다. 기본 키는 테이블 생성 시 또는 나중에 만들 수 있습니다. 테이블을 생성할 때 ID 필드가 기본 키가 되기로 결정했다고 가정해 보겠습니다. 그러면 다음과 같은 방식으로 기본 키를 추가할 수 있습니다:

CREATE TABLE Table_example ( ID INTEGER NOT NULL, NAME VARCHAR(80), PRICE_1 DOUBLE PRECISION, CONSTRAINT pkTable PRIMARY KEY (ID));

table_example 테이블에 기본 키를 생성하기 위해 무엇을 했을까요? 테이블 정의에서 무엇이 변경되었는지 살펴보겠습니다. 첫째, ID 컬럼에 NOT NULL 정의가 추가되었습니다. 기본 키는 고유해야 하고 정의되지 않은 값이 금지되어야 하므로 중요합니다. 그리고 NULL은 아시다시피 정의되지 않은 값입니다. 따라서 기본 키에 포함된 모든 필드는 NOT NULL 제약 조건을 가져야 합니다. 기본 키 생성을 완료하려면 테이블 끝에 다음을 작성해야 합니다: CONSTRAINT ()

제약 조건의 전체 구문은 “데이터베이스 제약 조건” 장에서 확인할 수 있으며, 기본 키 예시의 경우 다음과 같습니다:

CONSTRAINT pkTable PRIMARY KEY (ID)

여기서 pkTable은 기본 키의 이름이고, ID는 포함된 컬럼입니다. 이러한 기본 키 정의 방식은 테이블을 대량으로 생성할 때(예: 다양한 CASE 도구에서 얻은 스크립트를 기반으로 데이터베이스 프로토타입을 구축할 때) 편리합니다. 하지만 이미 존재하고 데이터가 채워진 테이블에 기본 키를 추가/삭제해야 하는 경우는 어떻게 해야 할까요? 이를 위해 ALTER TABLE 명령의 또 다른 확장을 적용해야 합니다. 테이블에 기본 키를 추가하는 예:

ALTER TABLE TABLE_EXAMPLE ADD CONSTRAINT FF PRIMARY KEY (ID);

따라서 Table_example 테이블은 테이블과 함께 생성되었을 때의 이전 예와 정확히 동일한 기본 키를 갖게 됩니다. 기본 키를 삭제하려면 다음 명령을 입력해야 합니다:

ALTER TABLE Table_example DROP CONSTRAINT pkTable;

이렇게 하면 pkTable이라는 이름의 키가 데이터베이스에서 제거됩니다.

생성기(Generators) - 기본 키의 가장 좋은 친구

기본 키의 구현에 대해 몇 마디 말해야 합니다. 기본 키는 고유성을 유지하기 위한 것이므로 한 테이블의 두 레코드는 이 키의 동일한 값을 가질 수 없습니다. 즉, 조건을 충족하려면 테이블에 새 레코드를 삽입할 때 InterBase가 테이블의 모든 레코드를 확인하고 해당 값이 테이블에 존재하는지 여부를 알아내야 합니다. 빠른 검색을 위해 InterBase에는 인덱스 메커니즘, 즉 테이블에서 레코드를 매우 빠르게 찾을 수 있는 특별한 InterBase 객체가 있습니다. 따라서 기본 키를 생성하고 삭제할 때 기본 키에 포함된 필드(또는 필드들)에 대한 인덱스가 생성되거나 삭제됩니다.

앞서 말했듯이 기본 키는 여러 필드를 포함할 수 있습니다. 따라서 이러한 필드 값의 조합의 고유성을 확인할 수 있습니다. 예를 들어 ID와 NAME 필드에 키를 정의하면 서버는 테이블에 이러한 필드의 동일한 조합이 없는지 제어합니다. 즉, ID 값이 1이고 “Ivanov”, 2이고 “Ivanov"인 필드 조합은 ID 필드 값이 다르므로 올바릅니다.

따라서 기본 키는 모든 유형의 여러 필드를 포함할 수 있습니다. 그러나 실제로 가장 일반적인 키 유형은 카운터, 즉 증가하는 값을 포함하는 정수 필드입니다. 왜 그럴까요? 이는 자연 키와 대체 키 사이의 오랜 논쟁을 반영합니다. 자연 키 개념은 데이터베이스가 반영하는 데이터 영역에 실제로 존재하는 값을 키로 사용하려고 해야 한다고 말합니다. 예를 들어 여권 사무소용 사람 등록 시스템을 개발한다면 이 개념에 따르면 여권 번호와 시리즈의 조합을 기본 키로 사용해야 합니다. 실제로 모든 사람은 여권 번호와 시리즈의 고유한 조합을 가져야 합니다. 그러나 사람이 일생 동안 여권을 변경할 수 있다는 사실(특정 연령 도달, 결혼 등)은 어떻게 처리해야 할까요? 이 경우 특정 사람에 대응하는 여권 번호와 시리즈를 변경해야 하며, 즉 실제로 기본 키를 변경해야 합니다. 이는 데이터베이스 애플리케이션 개발 관점에서 바람직하지 않습니다. 테이블 간의 분기된 통신 시스템(다음 장에서 다룰)을 고려할 때 개발자는 이 상황을 제어하기 위해 많은 노력을 기울여야 할 것입니다.

따라서, 대부분의 경우 대체 키가 사용됩니다. 대체 키는 인공적, 즉 우리 데이터베이스가 설명하는 데이터 도메인에 존재하지 않으며, 데이터베이스 애플리케이션 개발의 편의를 위해 인위적으로 생성된 것을 의미합니다. 앞서 말했듯이, 일반적으로 카운터가 기본 키입니다. Paradox 및 MS SQL과 같은 일부 DBMS에는 카운터(자동 증가)라는 특수 유형이 있습니다. 테이블에 새 레코드를 추가할 때 이 유형의 필드 값은 증가분(보통 1씩)만큼 자동으로 증가합니다. InterBase에는 카운터 유형의 필드가 없지만, 이러한 동작은 구현할 수 있습니다. 테이블에 레코드를 추가할 때 자동으로 채워질 필드를 만들기 위해 리소스 모음이 사용됩니다. 그 중 첫 번째는 생성기입니다.

생성기란 무엇일까요? 간단히 말하면, 생성기는 이름이 지정된 카운터입니다. 데이터베이스 내에서 카운터를 만들고, 이 데이터베이스 내에서 고유한 이름을 부여하고, 이 카운터의 값을 제어할 수 있습니다. 그것이 생성기가 됩니다. 다음은 이를 설명하는 DDL 문의 예입니다:

CREATE GENERATOR g1; SET GENERATOR g1 TO 2445;

이 예제의 첫 번째 줄에서는 g1이라는 이름의 생성기가 생성되고, 두 번째 줄에서는 이 생성기에 값 2445가 할당됩니다. 이제 얻은 생성기를 어떻게 사용할지에 대한 질문이 있습니다. InterBase에는 생성기 값을 가져오고 변경하기 위한 내장 함수 GEN_ID가 있습니다. 이 함수는 생성기의 이름과 해당 생성기에 적용할 증가분 값을 매개변수로 받아, 증가분을 더한 결과로 얻은 생성기 값에 해당하는 정수 값을 반환합니다. 다음은 트리거 또는 저장 프로시저에서 GEN_ID 함수를 호출하는 예입니다:

Current_value = GEN_ID (g1, 1)

생성기 값을 받으려면 다음 쿼리를 사용할 수 있습니다:

SELECT GEN_ID(g1, 1)FROM RDB$ DATABASE

RDB$ DATABASE 테이블은 항상 하나의 레코드만 포함하므로, 주어진 쿼리의 결과로 생성기 g1의 값을 받게 됩니다.

여기서 current_value는 변수입니다(다음 장에서 InterBase에서 변수를 사용하는 방법에 대한 정보를 찾을 수 있습니다), g1 - 생성기, 1 - 증가분. 이 예제에서는 생성기 g1의 값에 증가분 1을 더한 후 변수 current_value에 들어가게 됩니다, 즉 생성기의 다음 값입니다. 증가분이 1이 아닐 수도 있다는 점에 주의하세요! 게다가 음수일 수도 있습니다: Current_value = GEN_ID (g1, -23)

이 함수를 실행한 결과, 생성기 g1의 현재 값은 23만큼 감소합니다. 보시다시피, 생성기의 가능한 응용 범위는 상당히 넓습니다 - 기본 키 값을 얻는 데만 사용할 수 있는 것이 아니라 데이터베이스의 전역 변경 사항을 추적하는 데도 사용할 수 있습니다.

데이터베이스에 익숙한 사람들은 “여러 클라이언트가 동시에 같은 테이블에 데이터를 넣으려고 하고 동시에 생성기를 ‘당기면’ 어떻게 될까? 그들은 같은 값이나 다른 값을 받게 될까?“라는 질문을 할 수 있습니다. 그들은 명확하게 서로 다른 생성기 값을 받게 됩니다. 생성기 값을 얻으려는 시도가 아무리 ‘동시적’이었더라도, 요청한 모든 사람은 고유한 값을 받게 됩니다. 이는 생성기의 ‘구조’에 의해 보장됩니다: 생성기는 서버의 가장 낮은 수준에서 작동하며 어떤 기록 및 삽입 프로세스도 이에 영향을 미치지 않습니다 - 생성기가 ‘트랜잭션 컨텍스트 밖에서’ 작동한다고 흔히 말합니다. 트랜잭션에 대해 알고 싶다면 “트랜잭션. 트랜잭션 매개변수” (1부) 장을 읽으세요; 생성기가 어떻게 구성되어 있는지 - “InterBase 데이터베이스 구조” (4부). 자, 생성기 덕분에 고유한 기본 키를 만들 수 있는 신뢰할 수 있는 메커니즘이 있습니다. 그러나 이 메커니즘을 사용할 수 있을까요? 생성기에서 받은 값을 기본 키 필드에 어떻게 넣을까요?

이를 위해 두 가지 방법이 있습니다 - 클라이언트 측에서 기본 키를 삽입하거나 서버 측에서 삽입하는 것입니다. 첫 번째 방법을 익히려면 “FIBPlus의 주요 구성 요소 사용” 장을 참조하고, 두 번째 방법을 이해하려면 “트리거” (1부) 장을 참조해야 합니다. 여기서는 두 방법의 핵심을 간략히 검토하겠습니다.

클라이언트 측에서 기본 키를 만드는 경우, 다음과 같은 일이 발생합니다. 데이터베이스에 삽입될 레코드가 생성될 때 GEN_ID 함수 호출(, 1)이 실행되고 받은 값이 이 레코드에 대체됩니다. 그런 다음 테이블에 삽입이 이루어지며, 고유한 기본 키를 받는 것이 보장됩니다.

두 번째 방법 - 서버 측에서 기본 키를 만드는 경우 - 일반적으로 클라이언트가 기본 키 값이 무엇인지에 대해 전혀 신경 쓸 필요가 없게 합니다. 이 경우 레코드를 삽입할 때 트리거가 작동합니다 - 테이블의 레코드를 삽입/삭제/업데이트할 때 모든 작업을 수행할 수 있는 특수 데이터베이스 객체입니다. 그리고 이 트리거에서 다음 작업이 수행됩니다: GEN_ID 함수 호출, 필요한 생성기 값 받기 및 테이블에 삽입. 두 번째 방법의 장점은 클라이언트 애플리케이션을 개발할 때 기본 키 생성에 대해 전혀 걱정할 필요가 없고, 필요한 트리거를 한 번만 작성하면 된다는 것입니다. 그러나 단점은 삽입 직후 애플리케이션에서 생성된 키 값을 받을 수 없다는 것입니다! 첫 번째 방법을 사용하면 기본 키 값을 받을 수 있지만, 삽입할 때마다 그 생성에 대해 신경 써야 합니다. 어떤 방법이 더 나은지 확실히 말하기는 어렵습니다. 모두 특정 문제에 달려 있습니다. 이 책의 뒷부분에서는 기본 키 작업에 대한 질문을 해결하는 가능한 변형을 고려할 것입니다.

결론

그래서, 이 장에서는 InterBase에서 테이블을 만들고 업데이트하는 방법과 기본 키를 처리하는 방법을 검토했습니다. 따라서, 조건부로 정적이라고 할 수 있는 InterBase의 주요 객체를 고려했습니다. 왜냐하면 그것들은 정보만 저장하고 변환을 수행하지 않기 때문입니다. 다음으로, 데이터베이스 내에서 정보 제어 및 정보 변환 방법에 대해 이야기하겠습니다.