PostgreSQLプログラミング：CREATE SEQUENCEを活用したID管理の具体例

2025-06-06

`CREATE SEQUENCE`とは？

CREATE SEQUENCEは、指定されたルールに従って昇順または降順に番号を生成する、データベースオブジェクトです。この番号は、複数のセッションから同時にアクセスしても衝突しないように保証されており、データベースの整合性を保つ上で非常に重要です。

なぜシーケンスが必要なのか？

同時実行性
複数のユーザーが同時にレコードを追加しようとしても、シーケンスがそれぞれのトランザクションに異なるIDを割り振るため、競合を防ぎます。
自動採番
手動でIDを管理する手間を省き、システムに任せることでエラーを減らします。
一意なIDの生成
データベースのテーブルで、レコードごとにユニークな識別子（主キー）を割り当てる際に便利です。

基本的な構文

CREATE SEQUENCE sequence_name
    [ INCREMENT BY increment ]
    [ MINVALUE minvalue | NO MINVALUE ]
    [ MAXVALUE maxvalue | NO MAXVALUE ]
    [ START WITH start ]
    [ CACHE cache_size ]
    [ CYCLE | NO CYCLE ]
    [ OWNED BY { table_name.column_name | NONE } ];

主要なオプションの説明

OWNED BY { table_name.column_name | NONE }: シーケンスを特定のテーブルの列に関連付けます。これにより、関連付けられた列またはテーブルが削除されたときに、シーケンスも自動的に削除されます。NONEを指定すると、シーケンスはどの列にも関連付けられません。
NO CYCLE: シーケンスがMAXVALUE（またはMINVALUE）に達したときにエラーを発生させ、それ以上値を生成しないように指定します。これがデフォルトです。
CYCLE: シーケンスがMAXVALUE（またはMINVALUE）に達したときに、MINVALUE（またはMAXVALUE）に戻って値を生成し続けるように指定します。
CACHE cache_size: 事前に割り当ててメモリに保持するシーケンス値の数を指定します。これにより、シーケンス値の取得パフォーマンスが向上しますが、クラッシュ時に未使用のキャッシュ値が失われる可能性があります。デフォルトは1です。
START WITH start: シーケンスが開始する値を指定します。デフォルトは昇順の場合は1、降順の場合は-1です。
MAXVALUE maxvalue: シーケンスが生成する最大値を指定します。
MINVALUE minvalue: シーケンスが生成する最小値を指定します。
INCREMENT BY increment: シーケンスが値を増減させる際の増分値を指定します。デフォルトは1です。負の値を指定すると、降順のシーケンスになります。
sequence_name: 作成するシーケンスの名前を指定します。

使用例

基本的なシーケンスの作成（昇順）

CREATE SEQUENCE my_sequence;

このシーケンスは、1から始まり、1ずつ増えていきます。

開始値と増分値を指定したシーケンスの作成

CREATE SEQUENCE order_id_seq
    START WITH 1001
    INCREMENT BY 10;

このシーケンスは1001から始まり、10ずつ増えていきます（1001, 1011, 1021...）。

降順のシーケンスの作成

CREATE SEQUENCE reverse_id_seq
    START WITH 100
    INCREMENT BY -1
    MINVALUE 1;

このシーケンスは100から始まり、1ずつ減っていき、最小値1に達するとそれ以上は生成しません。

テーブルの列に関連付ける（SERIAL型とほぼ同等）

PostgreSQLでは、SERIALやBIGSERIALというデータ型を使用すると、自動的にシーケンスが作成され、列に紐付けられます。これは、CREATE SEQUENCEとDEFAULT nextval('シーケンス名')を組み合わせたショートカットです。

CREATE TABLE products (
    product_id SERIAL PRIMARY KEY, -- SERIAL型は自動的にシーケンスを作成し、nextval()を設定
    product_name VARCHAR(255)
);

上記のSERIALは、内部的には以下とほぼ同じことをしています。

CREATE SEQUENCE products_product_id_seq; -- シーケンスの作成
CREATE TABLE products (
    product_id INTEGER NOT NULL DEFAULT nextval('products_product_id_seq') PRIMARY KEY,
    product_name VARCHAR(255)
);
ALTER SEQUENCE products_product_id_seq OWNED BY products.product_id; -- 列にシーケンスを関連付け

シーケンスから値を取得するには、以下の関数を使用します。

setval('sequence_name', value): シーケンスの現在の値を指定した値に設定します。
currval('sequence_name'): 現在のセッションでnextval()によって最後に取得されたシーケンスの値を取得します。nextval()が呼び出される前はエラーになります。
nextval('sequence_name'): シーケンスの次の値を取得し、シーケンスの内部カウンタを進めます。

SELECT nextval('my_sequence'); -- my_sequenceから次の値を取得
-- 結果例: 1

SELECT nextval('my_sequence'); -- my_sequenceから次の値を取得
-- 結果例: 2

SELECT currval('my_sequence'); -- 現在のセッションで最後に取得されたmy_sequenceの値を取得
-- 結果例: 2

SELECT setval('my_sequence', 100); -- my_sequenceの現在の値を100に設定
SELECT nextval('my_sequence'); -- 次の値は101になる
-- 結果例: 101

「ERROR: relation "sequence_name" already exists」

エラーの原因
指定したシーケンス名が、同じスキーマ内に既に存在する場合に発生します。これは、テーブル、ビュー、インデックスなど、他のリレーションの名前と重複している場合も含まれます。

トラブルシューティング

IF NOT EXISTS句を使用する
CREATE SEQUENCE IF NOT EXISTS sequence_name; のように記述することで、シーケンスが存在しない場合にのみ作成し、既に存在する場合はエラーを発生させずにスキップできます。スクリプトなどで繰り返し実行する場合に便利です。
既存のシーケンスを削除する
DROP SEQUENCE sequence_name; コマンドで既存のシーケンスを削除してから、再度作成します。ただし、既存のシーケンスを使用しているテーブルやアプリケーションがないか、十分に確認してください。
別のシーケンス名を使用する
最も簡単な解決策です。

シーケンスの値が重複する（「duplicate key value violates unique constraint」）

エラーの原因
これはCREATE SEQUENCE自体ではなく、シーケンスを使って主キーなどのユニーク制約のある列に値を挿入する際に発生する最も一般的なエラーです。主な原因は以下の通りです。

setval()関数の誤用
setval()関数でシーケンスの現在値を誤って設定してしまい、既存のデータと重複する値が生成されるようになった場合。
データインポート/リストア
データを大量にインポートしたり、データベースをリストアしたりする際に、シーケンスの値がテーブルの最大ID値に追いついていない場合。
手動でIDを挿入してしまった
アプリケーションやDML（INSERT文）で、シーケンスを使わずにID列に直接値を挿入し、その値がシーケンスが次に生成する値よりも大きくなってしまった場合。

トラブルシューティング
シーケンスの現在の値を、テーブルの既存のIDの最大値より大きい値にリセットする必要があります。

-- 対象テーブルの最大IDを取得
SELECT MAX(id_column_name) FROM your_table_name;

-- シーケンスの現在値を設定
-- 通常、シーケンス名には「テーブル名_列名_seq」のような命名規則が使われます。
-- 例: productsテーブルのproduct_id列に紐づくシーケンスなら products_product_id_seq
SELECT setval('your_sequence_name', (SELECT COALESCE(MAX(id_column_name), 1) FROM your_table_name));

-- もしシーケンスの次の値として最大値の次から始めたい場合は、+1 を加えることもあります
-- SELECT setval('your_sequence_name', (SELECT COALESCE(MAX(id_column_name), 0) FROM your_table_name) + 1);

COALESCE(MAX(id_column_name), 1): もしテーブルにデータが全くない場合（MAX()がNULLを返す場合）に、シーケンスの開始値を1に設定するためのものです。テーブルにデータがない状態でシーケンスの値を0にすると、次にnextval()を呼んだときに1が返ってきます。

「ERROR: nextval: reached maximum value of sequence "sequence_name" (current value: XXXXXXXXXX)」

エラーの原因
シーケンスにMAXVALUEが設定されており、シーケンスがその最大値に達した場合に発生します。デフォルトではNO CYCLEが設定されているため、最大値を超えるとエラーになります。

トラブルシューティング

新しいシーケンスを作成する
既存のシーケンスの目的が終了した場合は、新しいシーケンスを作成して切り替えることも検討します。
MAXVALUEを増やす
ALTER SEQUENCE sequence_name MAXVALUE new_max_value; で、シーケンスの最大値をより大きな値に設定します。
シーケンスをCYCLEにする
ALTER SEQUENCE sequence_name CYCLE; を実行すると、最大値に達した後に最小値に戻って値を生成し続けるようになります。ただし、これにより同じIDが再利用される可能性があるため、主キーとして使用している場合は注意が必要です。

エラーの原因
currval('sequence_name')は、現在のセッションで最後にnextval('sequence_name')が呼び出されて生成された値を返します。そのため、一度もnextval()が呼び出されていないセッションでcurrval()を呼び出すとエラーになります。

シーケンスの作成と基本操作 (SQL)

まず、プログラミングから利用するシーケンスをデータベースに作成します。

シーケンスの作成

-- シンプルな昇順シーケンス
CREATE SEQUENCE IF NOT EXISTS user_id_seq
    START WITH 1
    INCREMENT BY 1
    NO MINVALUE
    NO MAXVALUE
    CACHE 1; -- パフォーマンスのためにキャッシュを使用することもできますが、番号の連続性に影響する可能性あり

-- 降順シーケンスの例
CREATE SEQUENCE IF NOT EXISTS audit_log_seq
    START WITH 1000000
    INCREMENT BY -1
    MINVALUE 1
    NO MAXVALUE
    CACHE 1;

テーブルとシーケンスの関連付け（SERIAL型の場合）

通常、PostgreSQLではSERIAL型を使用することで、自動的にシーケンスが作成され、列に紐付けられます。これは最も一般的な方法です。

CREATE TABLE users (
    id SERIAL PRIMARY KEY, -- SERIAL型が自動的にシーケンスを作成し、デフォルト値を設定
    username VARCHAR(255) NOT NULL,
    email VARCHAR(255) UNIQUE
);

-- SERIAL型が内部的に行っていること（次のように明示的に書くことも可能）
-- CREATE SEQUENCE users_id_seq;
-- CREATE TABLE users (
--     id BIGINT NOT NULL DEFAULT nextval('users_id_seq') PRIMARY KEY,
--     username VARCHAR(255) NOT NULL,
--     email VARCHAR(255) UNIQUE
-- );
-- ALTER SEQUENCE users_id_seq OWNED BY users.id; -- シーケンスと列の関連付け

プログラミング言語からの利用例

ここでは、PythonとJavaを用いて、上記で作成したシーケンスやSERIAL型を利用したテーブルに対するプログラミング例を示します。

Python (psycopg2)

PythonでPostgreSQLを操作するには、psycopg2ライブラリがよく使われます。

import psycopg2
from psycopg2 import Error

def connect_db():
    """データベースに接続する関数"""
    try:
        conn = psycopg2.connect(
            user="your_username",
            password="your_password",
            host="localhost",
            port="5432",
            database="your_database_name"
        )
        return conn
    except Error as e:
        print(f"データベース接続エラー: {e}")
        return None

def create_user(username, email):
    """ユーザーを作成し、SERIAL型で自動生成されるIDを取得する関数"""
    conn = connect_db()
    if conn:
        try:
            cursor = conn.cursor()
            # SERIAL型を使用する場合、ID列はINSERT文で指定する必要がない
            # RETURNING id で挿入されたIDを取得する
            insert_query = """
            INSERT INTO users (username, email)
            VALUES (%s, %s)
            RETURNING id;
            """
            cursor.execute(insert_query, (username, email))
            user_id = cursor.fetchone()[0]
            conn.commit()
            print(f"ユーザー '{username}' がID: {user_id} で作成されました。")
            return user_id
        except Error as e:
            conn.rollback()
            print(f"ユーザー作成エラー: {e}")
            return None
        finally:
            if conn:
                cursor.close()
                conn.close()

def create_audit_log_manual_id(message):
    """手動でシーケンスからIDを取得して監査ログを作成する関数"""
    conn = connect_db()
    if conn:
        try:
            cursor = conn.cursor()
            
            # nextval() でシーケンスから次のIDを取得
            get_id_query = "SELECT nextval('audit_log_seq');"
            cursor.execute(get_id_query)
            log_id = cursor.fetchone()[0]

            insert_query = """
            INSERT INTO audit_logs (id, message, created_at)
            VALUES (%s, %s, NOW());
            """
            cursor.execute(insert_query, (log_id, message))
            conn.commit()
            print(f"監査ログがID: {log_id} で作成されました。")
            return log_id
        except Error as e:
            conn.rollback()
            print(f"監査ログ作成エラー: {e}")
            return None
        finally:
            if conn:
                cursor.close()
                conn.close()

if __name__ == "__main__":
    # シーケンスとテーブルを事前に作成しておく必要があります
    # SQLクライアントなどで以下のSQLを実行してください:
    # CREATE TABLE users (id SERIAL PRIMARY KEY, username VARCHAR(255) NOT NULL, email VARCHAR(255) UNIQUE);
    # CREATE TABLE audit_logs (id BIGINT PRIMARY KEY, message TEXT, created_at TIMESTAMP);
    # CREATE SEQUENCE audit_log_seq START WITH 1000000 INCREMENT BY -1 MINVALUE 1 NO MAXVALUE CACHE 1;

    print("--- SERIAL型を使用したユーザー作成 ---")
    new_user_id = create_user("alice_user", "[email protected]")
    new_user_id = create_user("bob_user", "[email protected]")

    print("\n--- シーケンスからIDを取得して監査ログ作成 ---")
    create_audit_log_manual_id("ユーザー 'alice_user' がログインしました。")
    create_audit_log_manual_id("データが更新されました。")

    # シーケンスの現在の値を確認（デバッグ用）
    conn = connect_db()
    if conn:
        cursor = conn.cursor()
        cursor.execute("SELECT last_value FROM audit_log_seq;")
        current_audit_log_seq_value = cursor.fetchone()[0]
        print(f"\n現在の audit_log_seq の値: {current_audit_log_seq_value}")
        cursor.close()
        conn.close()

Java (JDBC)

JavaでPostgreSQLを操作するには、JDBCドライバーを使用します。pom.xmlにpostgresqlドライバーを追加してください。

<dependency>
    <groupId>org.postgresql</groupId>
    <artifactId>postgresql</artifactId>
    <version>42.7.3</version> </dependency>

import java.sql.*;

public class PostgreSQLSequenceExample {

    private static final String DB_URL = "jdbc:postgresql://localhost:5432/your_database_name";
    private static final String DB_USER = "your_username";
    private static final String DB_PASSWORD = "your_password";

    public static Connection connect() throws SQLException {
        return DriverManager.getConnection(DB_URL, DB_USER, DB_PASSWORD);
    }

    public static int createUser(String username, String email) {
        String insertSql = "INSERT INTO users (username, email) VALUES (?, ?) RETURNING id;";
        int userId = -1;

        try (Connection conn = connect();
             PreparedStatement pstmt = conn.prepareStatement(insertSql)) {

            pstmt.setString(1, username);
            pstmt.setString(2, email);

            // executeQuery() ではなく executeUpdate() で実行し、結果セットでIDを取得
            // RETURNING句を使用する場合、executeQuery() と ResultSet でIDを取得するのが一般的
            ResultSet rs = pstmt.executeQuery(); 
            if (rs.next()) {
                userId = rs.getInt("id");
            }
            System.out.println("ユーザー '" + username + "' がID: " + userId + " で作成されました。");
        } catch (SQLException e) {
            System.err.println("ユーザー作成エラー: " + e.getMessage());
        }
        return userId;
    }

    public static long createAuditLogManualId(String message) {
        long logId = -1;
        String getSeqValSql = "SELECT nextval('audit_log_seq');";
        String insertSql = "INSERT INTO audit_logs (id, message, created_at) VALUES (?, ?, NOW());";

        try (Connection conn = connect()) {
            conn.setAutoCommit(false); // トランザクションを開始

            // 1. シーケンスからIDを取得
            try (Statement stmt = conn.createStatement();
                 ResultSet rs = stmt.executeQuery(getSeqValSql)) {
                if (rs.next()) {
                    logId = rs.getLong(1);
                }
            }

            // 2. 取得したIDを使ってデータを挿入
            try (PreparedStatement pstmt = conn.prepareStatement(insertSql)) {
                pstmt.setLong(1, logId);
                pstmt.setString(2, message);
                pstmt.executeUpdate();
            }

            conn.commit(); // コミット
            System.out.println("監査ログがID: " + logId + " で作成されました。");

        } catch (SQLException e) {
            System.err.println("監査ログ作成エラー: " + e.getMessage());
            // ロールバック処理
            try (Connection conn = connect()) {
                conn.rollback();
            } catch (SQLException rollbackEx) {
                System.err.println("ロールバックエラー: " + rollbackEx.getMessage());
            }
        }
        return logId;
    }

    public static void main(String[] args) {
        // シーケンスとテーブルを事前に作成しておく必要があります
        // SQLクライアントなどで以下のSQLを実行してください:
        // CREATE TABLE users (id SERIAL PRIMARY KEY, username VARCHAR(255) NOT NULL, email VARCHAR(255) UNIQUE);
        // CREATE TABLE audit_logs (id BIGINT PRIMARY KEY, message TEXT, created_at TIMESTAMP);
        // CREATE SEQUENCE audit_log_seq START WITH 1000000 INCREMENT BY -1 MINVALUE 1 NO MAXVALUE CACHE 1;

        System.out.println("--- SERIAL型を使用したユーザー作成 ---");
        createUser("charlie_user", "[email protected]");
        createUser("david_user", "[email protected]");

        System.out.println("\n--- シーケンスからIDを取得して監査ログ作成 ---");
        createAuditLogManualId("ユーザー 'charlie_user' がログインしました。");
        createAuditLogManualId("システム設定が変更されました。");

        // シーケンスの現在の値を確認（デバッグ用）
        try (Connection conn = connect();
             Statement stmt = conn.createStatement();
             ResultSet rs = stmt.executeQuery("SELECT last_value FROM audit_log_seq;")) {
            if (rs.next()) {
                System.out.println("\n現在の audit_log_seq の値: " + rs.getLong(1));
            }
        } catch (SQLException e) {
            System.err.println("シーケンス値取得エラー: " + e.getMessage());
        }
    }
}

エラーハンドリング
データベース操作では、接続エラー、SQL実行エラーなど、様々なエラーが発生する可能性があります。適切なエラーハンドリング（try-catchやtry-except、トランザクションのロールバックなど）を行うことが重要です。
トランザクション管理
nextval()は、トランザクションのロールバックの影響を受けません。つまり、nextval()で値を取得した後、そのトランザクションがロールバックされても、取得した値は消費されたままで、シーケンスのカウンタは元に戻りません。厳密な「ギャップレス」な採番が必要な場合は、シーケンスではなく、テーブルに排他ロックをかけるなどの別の方法を検討する必要があります（ただし、これはパフォーマンスに影響します）。
nextval()関数の手動利用
SERIAL型を使わない場合や、特定のシーケンスからIDを明示的に取得したい場合は、SELECT nextval('sequence_name')を使用します。この場合、nextval()でIDを取得した後に、そのIDをINSERT文に含めて実行します。
RETURNING id句
INSERT文でデータを挿入した直後に、自動生成されたIDを取得するには、RETURNING id句（idは対象の列名）を使用するのが最も効率的です。これにより、別のSELECT nextval()クエリを発行する必要がなくなります。
SERIAL型/IDENTITY列の利用
PostgreSQLで自動採番の主キーを使用する場合、SERIALまたはBIGSERIAL型（PostgreSQL 10以降ではIDENTITY列も推奨）を使うのが最も一般的で、簡潔です。これらの型を使用すると、データベース側でシーケンスの作成と列への紐付けが自動的に行われます。

IDENTITY 列 (PostgreSQL 10以降)

IDENTITY列は、SQL標準に準拠した自動採番の方法で、SERIAL型のより現代的な代替手段です。SERIAL型が内部的にシーケンスを使用するのに対し、IDENTITY列は列の定義の一部として自動生成の挙動を直接指定します。

特徴

GENERATED ALWAYS AS IDENTITY (常に自動生成) と GENERATED BY DEFAULT AS IDENTITY (手動挿入も可能) の2つのモードがある。
SERIAL型と同様に、内部的にシーケンスを使用する。
SQL標準に準拠している。

SQLでの定義例

CREATE TABLE products (
    product_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    product_name VARCHAR(255) NOT NULL,
    price NUMERIC(10, 2)
);

-- あるいは、手動挿入も許可する場合
CREATE TABLE orders (
    order_id BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
    customer_id INT NOT NULL,
    order_date TIMESTAMP DEFAULT NOW()
);

プログラミングからの利用 (Python/psycopg2 例)

SERIAL型と同様に、INSERT文でproduct_id列を指定する必要はありません。RETURNING句で挿入されたIDを取得します。

import psycopg2
from psycopg2 import Error

def create_product(product_name, price):
    conn = None
    try:
        conn = psycopg2.connect(
            user="your_username",
            password="your_password",
            host="localhost",
            port="5432",
            database="your_database_name"
        )
        cursor = conn.cursor()
        
        insert_query = """
        INSERT INTO products (product_name, price)
        VALUES (%s, %s)
        RETURNING product_id;
        """
        cursor.execute(insert_query, (product_name, price))
        product_id = cursor.fetchone()[0]
        conn.commit()
        print(f"製品 '{product_name}' がID: {product_id} で作成されました。")
        return product_id
    except Error as e:
        if conn:
            conn.rollback()
        print(f"製品作成エラー: {e}")
        return None
    finally:
        if conn:
            cursor.close()
            conn.close()

if __name__ == "__main__":
    # テーブルを事前に作成しておく必要があります
    # CREATE TABLE products (product_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, product_name VARCHAR(255) NOT NULL, price NUMERIC(10, 2));
    
    create_product("Laptop", 1200.00)
    create_product("Mouse", 25.50)

UUID (Universally Unique Identifier)

UUIDは、ネットワーク上の複数のシステムで衝突することなく一意なIDを生成できる128ビットの識別子です。主に、分散システムやオフライン環境でのデータ生成に適しています。

特徴

インデックスパフォーマンス
B-treeインデックスでは、シーケンシャルなIDに比べてインデックスの断片化が発生しやすく、パフォーマンスに影響を与える可能性がある。
シーケンシャルではない
IDは連続しないため、特定の順番を保証できない。
分散環境向き
複数のサーバーやサービスが独立してIDを生成できる。
グローバルな一意性
衝突する可能性が極めて低い。

SQLでの定義例

CREATE EXTENSION IF NOT EXISTS "uuid-ossp"; -- UUIDを生成するための拡張機能

CREATE TABLE documents (
    document_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), -- PostgreSQL 13以降
    -- または DEFAULT uuid_generate_v4(), (uuid-ossp拡張が必要)
    title VARCHAR(255) NOT NULL,
    content TEXT
);

uuid_generate_v4(): uuid-ossp拡張機能が必要なUUID生成関数。
gen_random_uuid(): PostgreSQL 13以降で利用可能な、標準で搭載されているUUID生成関数。

プログラミングからの利用 (Java/JDBC 例)

INSERT文でUUID列を指定する必要はありません。データベースがデフォルトでUUIDを生成します。RETURNING句で挿入されたUUIDを取得できます。

import java.sql.*;
import java.util.UUID; // Java標準のUUIDクラス

public class UUIDExample {

    private static final String DB_URL = "jdbc:postgresql://localhost:5432/your_database_name";
    private static final String DB_USER = "your_username";
    private static final String DB_PASSWORD = "your_password";

    public static Connection connect() throws SQLException {
        return DriverManager.getConnection(DB_URL, DB_USER, DB_PASSWORD);
    }

    public static UUID createDocument(String title, String content) {
        String insertSql = "INSERT INTO documents (title, content) VALUES (?, ?) RETURNING document_id;";
        UUID documentId = null;

        try (Connection conn = connect();
             PreparedStatement pstmt = conn.prepareStatement(insertSql)) {

            pstmt.setString(1, title);
            pstmt.setString(2, content);

            ResultSet rs = pstmt.executeQuery();
            if (rs.next()) {
                // UUID型の列からUUIDオブジェクトとして取得
                documentId = (UUID) rs.getObject("document_id");
            }
            System.out.println("ドキュメント '" + title + "' がID: " + documentId + " で作成されました。");
        } catch (SQLException e) {
            System.err.println("ドキュメント作成エラー: " + e.getMessage());
        }
        return documentId;
    }

    public static void main(String[] args) {
        // テーブルを事前に作成しておく必要があります
        // CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
        // CREATE TABLE documents (document_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), title VARCHAR(255) NOT NULL, content TEXT);

        createDocument("Meeting Minutes", "Discussed Q2 strategy.");
        createDocument("Project Plan", "Outline for new feature development.");
    }
}

アプリケーション層でのID生成

データベースの機能に頼らず、アプリケーションコード内でIDを生成する方法です。

特徴

衝突の可能性
複数のインスタンスが同時に稼働する場合、単純な採番ロジックではIDが衝突するリスクがある。
競合の管理が難しい
分散環境で一意性を保証するには、独自の仕組み（中央集権的なIDサーバー、楽観的ロックなど）が必要となり、複雑になる。
データベースの負荷軽減
データベースへの負荷を減らせる。
完全に制御可能
ID生成ロジックをアプリケーション側で自由に実装できる。

例: タイムスタンプと乱数を組み合わせる (Pythonの擬似コード)

import time
import random

def generate_unique_id():
    """タイムスタンプと乱数を組み合わせたID生成の擬似コード"""
    timestamp = int(time.time() * 1000) # ミリ秒単位のタイムスタンプ
    random_part = random.randint(0, 999999) # 6桁の乱数
    return f"{timestamp}-{random_part}"

def insert_data_with_app_id(data_value):
    unique_id = generate_unique_id()
    # データベースへの挿入処理 (SQLを直接実行)
    # INSERT INTO my_table (id, data) VALUES ('generated_id', 'data_value');
    print(f"アプリケーション生成ID: {unique_id} でデータを挿入します。")
    return unique_id

# 注意: この方法は分散環境での衝突リスクが高いため、実運用には適していません。
# 衝突を避けるためには、より堅牢なアルゴリズム（例: Snowflake ID）や
# 中央集権的なID生成サービスが必要です。

複合主キー / 自然キー

単一の自動生成IDではなく、複数の列を組み合わせて主キーを構成したり（複合主キー）、データそのものに一意性がある属性（自然キー）を主キーとして利用したりする方法です。

特徴

一意性の保証
組み合わせる列が確実に一意であることをデータベースの制約で保証する必要がある。
更新コスト
自然キーが変更される可能性がある場合、関連する外部キーも更新する必要がある。
ビジネスロジックとの関連性
IDがビジネス上の意味を持つため、理解しやすい場合がある。

SQLでの定義例

-- 複合主キーの例 (注文IDと商品IDの組み合わせで明細を一意に識別)
CREATE TABLE order_items (
    order_id INT NOT NULL,
    item_number INT NOT NULL,
    product_id INT NOT NULL,
    quantity INT,
    PRIMARY KEY (order_id, item_number) -- 複合主キー
);

-- 自然キーの例 (ISBNは書籍の一意な識別子)
CREATE TABLE books (
    isbn VARCHAR(13) PRIMARY KEY, -- ISBNを自然キーとして使用
    title VARCHAR(255) NOT NULL,
    author VARCHAR(255)
);

プログラミングからの利用 (Python/psycopg2 例)

複合主キーや自然キーの場合、IDはアプリケーション側で提供するか、他のテーブルから取得することになります。

def add_order_item(order_id, item_number, product_id, quantity):
    conn = None
    try:
        conn = psycopg2.connect(...)
        cursor = conn.cursor()
        
        insert_query = """
        INSERT INTO order_items (order_id, item_number, product_id, quantity)
        VALUES (%s, %s, %s, %s);
        """
        cursor.execute(insert_query, (order_id, item_number, product_id, quantity))
        conn.commit()
        print(f"注文ID: {order_id}, アイテム番号: {item_number} の明細が追加されました。")
    except Error as e:
        if conn:
            conn.rollback()
        print(f"注文明細追加エラー: {e}")
    finally:
        if conn:
            cursor.close()
            conn.close()

def add_book(isbn, title, author):
    conn = None
    try:
        conn = psycopg2.connect(...)
        cursor = conn.cursor()
        
        insert_query = """
        INSERT INTO books (isbn, title, author)
        VALUES (%s, %s, %s);
        """
        cursor.execute(insert_query, (isbn, title, author))
        conn.commit()
        print(f"書籍 '{title}' (ISBN: {isbn}) が追加されました。")
    except Error as e:
        if conn:
            conn.rollback()
        print(f"書籍追加エラー: {e}")
    finally:
        if conn:
            cursor.close()
            conn.close()

CREATE SEQUENCE（またはSERIAL/IDENTITY列）は、PostgreSQLで最も効率的かつ安全に単一の連続する整数IDを生成する方法です。ほとんどのユースケースでこれが推奨されます。

しかし、以下のような特殊な要件がある場合は、代替手段を検討すると良いでしょう。

厳密なSQL標準準拠が必要な場合
IDENTITY列がSERIALよりも推奨されます。
IDがビジネスロジックと密接に関連している場合
自然キーや複合主キーが選択肢になり得ます。
グローバルな一意性が必要な分散システム
UUIDが適しています。

どの方法を選択するかは、アプリケーションの要件、システムの規模、分散の度合い、パフォーマンス特性などを総合的に考慮して決定する必要があります。 PostgreSQLのCREATE SEQUENCEは、一意な整数IDを生成する標準的で効率的な方法ですが、いくつかの代替手段も存在します。これらの代替手段は、特定のユースケースや要件（分散システム、IDの推測防止、データ型など）に応じて選択されます。

SERIALおよびBIGSERIALは、内部的にシーケンスを使用する便利な「疑似型」ですが、PostgreSQL 10以降ではSQL標準に準拠したIDENTITY列が導入されました。これはSERIALよりも明示的で、より厳密な制御が可能です。

特徴

OWNED BYの自動設定
SERIALと同様に、自動的にシーケンスが作成され、列に紐付けられます。
GENERATED ALWAYSとGENERATED BY DEFAULT
- GENERATED ALWAYS AS IDENTITY: INSERT時にIDを明示的に指定することを禁止します。指定しようとするとエラーになります。
- GENERATED BY DEFAULT AS IDENTITY: INSERT時にIDを明示的に指定できます。指定しなかった場合は自動生成されます。
SQL標準準拠
SERIALよりも標準に近いです。

構文例

CREATE TABLE products_identity (
    product_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    product_name VARCHAR(255)
);

CREATE TABLE orders_identity (
    order_id INT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
    order_date DATE
);

プログラミングからの利用
SERIAL型の場合と同様に、INSERT文でID列を省略するか、DEFAULTキーワードを使用します。RETURNING id句で挿入されたIDを取得するのも同様です。

-- `GENERATED ALWAYS` の場合
INSERT INTO products_identity (product_name) VALUES ('Laptop') RETURNING product_id;

-- `GENERATED BY DEFAULT` の場合
INSERT INTO orders_identity (order_date) VALUES (CURRENT_DATE) RETURNING order_id;
-- IDを明示的に指定することも可能（衝突に注意）
INSERT INTO orders_identity (order_id, order_date) VALUES (1000, CURRENT_DATE) RETURNING order_id;

SERIALとの比較

IDENTITY列はGENERATED ALWAYSを指定することで、IDの手動挿入をより厳密に制御できます。SERIALの場合、IDを明示的に指定することが可能で、これがシーケンスとの値の重複を引き起こす原因となることがあります。
SERIALはPostgreSQL独自の拡張であり、IDENTITY列はSQL標準です。

UUIDは、128ビットの数値で、非常に低い確率で重複する可能性のあるグローバルに一意な識別子です。分散システムや、IDが推測されることを防ぎたい場合に特に有用です。

特徴

オフライン生成
データベースに接続せずにアプリケーション側でUUIDを生成することも可能です。
推測困難性
連番ではないため、セキュリティ上のリスク（例: ユーザーIDの推測）を軽減します。
グローバルな一意性
複数のデータベースやシステム間で衝突の心配が非常に少ないです。

種類と性能

UUID v6/v7 (新しい規格)
時間ベースの要素を含みつつランダム性も持つ、ソート可能なUUIDです。インデックス性能と一意性のバランスが良いと期待されています。PostgreSQL 17でgen_random_uuid()がUUID v7をサポートする予定です。
UUID v4
完全にランダムです。最も一般的ですが、ランダム性が高いためB-treeインデックスのパフォーマンスに影響を与える可能性があります（インデックスのフラグメンテーションやI/Oの増加）。
UUID v1
MACアドレスとタイムスタンプに基づきます。並べ替え可能ですが、MACアドレスを漏洩する可能性があります。

PostgreSQLでのUUIDの利用

uuidデータ型を使用

CREATE TABLE messages (
    message_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), -- gen_random_uuid() はPostgreSQL 13以降で利用可能
    content TEXT
);

古いPostgreSQLバージョンでのuuid-ossp拡張
PostgreSQL 12以前では、gen_random_uuid()がないため、uuid-ossp拡張をインストールしてuuid_generate_v4()などの関数を使用します。
```
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

CREATE TABLE old_messages (
    message_id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
    content TEXT
);
```

プログラミングからの利用
通常、DEFAULT gen_random_uuid()（またはuuid_generate_v4()）を設定しておけば、SERIAL型と同様にINSERT時にID列を省略するだけで自動生成されます。

-- Python (psycopg2)
insert_query = "INSERT INTO messages (content) VALUES (%s) RETURNING message_id;"
cursor.execute(insert_query, ("Hello, UUID!",))
message_uuid = cursor.fetchone()[0]
print(f"メッセージがUUID: {message_uuid} で作成されました。")

UUIDの考慮事項

可読性
人間にとっては読みにくく、覚えにくいです。
インデックス性能
ランダムなUUID (v4) はB-treeインデックスの効率を低下させる可能性があります。
ストレージサイズ
UUIDは整数IDよりも多くのストレージを消費します（16バイト vs 4バイトまたは8バイト）。

データベースのシーケンス機能に依存せず、アプリケーション側でIDを生成し、それをデータベースに挿入する方法です。

例

Squids
短い文字列でIDを表現し、数値IDとの変換を可能にするライブラリ。
ULID (Universally Unique Lexicographically Sortable Identifier)
UUID v7と同様に、時間ベースでソート可能なIDです。
Twitter SnowflakeのようなタイムスタンプとノードIDを組み合わせたID生成アルゴリズム

特徴

オフライン生成
データベースに接続せずにIDを生成できます。
柔軟性
特定の要件（例: シャーディング、分散システムにおけるIDの衝突回避、IDの形式カスタマイズ）に合わせてIDを生成できます。
データベースの負荷軽減
ID生成のロジックをアプリケーション層にオフロードできます。

プログラミングからの利用

import uuid # Python標準ライブラリのUUIDモジュール

def create_order_app_generated_id(item_name, quantity):
    conn = connect_db()
    if conn:
        try:
            cursor = conn.cursor()
            # アプリケーション側でUUIDを生成
            order_id = str(uuid.uuid4()) # UUID v4を文字列として取得

            insert_query = """
            INSERT INTO app_generated_orders (order_id, item_name, quantity, created_at)
            VALUES (%s, %s, %s, NOW());
            """
            cursor.execute(insert_query, (order_id, item_name, quantity))
            conn.commit()
            print(f"注文がID: {order_id} で作成されました。")
            return order_id
        except Error as e:
            conn.rollback()
            print(f"注文作成エラー: {e}")
            return None
        finally:
            if conn:
                cursor.close()
                conn.close()

# SQLでテーブルを作成（DEFAULTは設定しない）
# CREATE TABLE app_generated_orders (
#     order_id VARCHAR(36) PRIMARY KEY, -- UUIDはVARCHAR(36)で格納可能
#     item_name VARCHAR(255),
#     quantity INT,
#     created_at TIMESTAMP DEFAULT NOW()
# );

考慮事項

可読性
生成されるIDの形式によります。
テストの複雑性
ID生成ロジックがアプリケーションに移動するため、テストが複雑になる可能性があります。
衝突管理
分散環境でIDを生成する場合、衝突を避けるための堅牢なアルゴリズムが必要です。UUIDはその目的のために設計されています。

CREATE SEQUENCEは、パフォーマンスのためにギャップ（欠番）を許容します。厳密にギャップレスな連番が必要な場合は、データベースレベルで排他ロックをかけて手動で採番テーブルを更新するなどの方法が考えられます。

特徴

厳密な連番
番号に一切の欠番が許されません。

問題点

複雑な実装
トランザクション、ロック、エラーハンドリングなどを慎重に管理する必要があります。
重大なパフォーマンスボトルネック
同時実行性が大幅に低下し、スケーラビリティが損なわれます。特に高負荷なシステムでは避けるべきです。

ほとんどのユースケースでは、この方法は必要ありません。 ギャップがあること（例: トランザクションのロールバックやキャッシュの消失による欠番）がビジネスロジックに影響しないか、よく検討してください。もしビジネス要件が「請求書番号のように物理的な書類と紐付けられる番号」などである場合、その番号はデータベースの主キーとは別に管理し、ギャップを許容しないようにアプリケーションロジックで制御することが多いです。

方法	特徴	メリット	デメリット	ユースケース
`IDENTITY`列	SQL標準。`SERIAL`の進化版。	簡潔、データベースでの自動管理、`GENERATED ALWAYS`で厳密な制御。	整数IDのため、分散システムでは衝突の可能性あり。	ほとんどの単一データベースシステムにおける主キー。
UUID	128ビットのグローバルに一意な識別子。	グローバルな一意性、推測困難性、分散システムとの相性。	ストレージ消費大、インデックス性能低下（特にUUID v4）、人間には読みにくい。	分散システム、IDの推測防止、セキュリティ要件が高い場合。
アプリケーション層でのID生成	アプリケーションがID生成ロジックを管理。	高い柔軟性、特定の要件に合わせたカスタマイズ、DB負荷軽減。	ID生成ロジックの複雑化、衝突管理の責任。	複雑なID要件、シャーディング、オフライン操作。
ギャップレスなシーケンス	厳密な連番。	番号の欠番がない。	非常に低いパフォーマンス、同時実行性のボトルネック、実装の複雑性。	ほとんどのWebアプリケーションでは非推奨。厳密な監査要件など極めて稀なケース。

PostgreSQLプログラミング：CREATE SEQUENCEを活用したID管理の具体例

CREATE SEQUENCEとは？

なぜシーケンスが必要なのか？

基本的な構文

主要なオプションの説明

使用例

基本的なシーケンスの作成（昇順）

開始値と増分値を指定したシーケンスの作成

降順のシーケンスの作成

テーブルの列に関連付ける（SERIAL型とほぼ同等）

「ERROR: relation "sequence_name" already exists」

シーケンスの値が重複する（「duplicate key value violates unique constraint」）

「ERROR: nextval: reached maximum value of sequence "sequence_name" (current value: XXXXXXXXXX)」

シーケンスの作成と基本操作 (SQL)

プログラミング言語からの利用例

Python (psycopg2)

Java (JDBC)

IDENTITY 列 (PostgreSQL 10以降)

UUID (Universally Unique Identifier)

アプリケーション層でのID生成

複合主キー / 自然キー

`CREATE SEQUENCE`とは？