PostgreSQLの配列列はどのように機能しますか？

Question

Accepted Answer

PostgreSQLは**配列**列をサポートしています — 単一の列に同じ型の*複数の値*を保持できます。これはPostgresの特徴的な機能で、別のテーブルを使用せずにリスト（タグ、ロール、スコア）を保存でき、クエリ実行のための演算子と関数を備えています。

## 配列の定義と挿入

```sql
CREATE TABLE posts (
  id SERIAL PRIMARY KEY,
  title TEXT,
  tags TEXT[]                         -- an array of text
);

INSERT INTO posts (title, tags) VALUES
  ('Hello', ARRAY['ruby', 'web']),    -- ARRAY[] syntax
  ('World', '{"news", "tech"}');       -- or curly-brace literal
```

`type[]`構文は配列列を宣言します。`ARRAY[...]`または`'{...}'`リテラル構文で挿入します。

## 配列のクエリ実行

```sql
-- ANY — does the array contain a value?
SELECT * FROM posts WHERE 'ruby' = ANY(tags);

-- @> containment — does the array contain ALL of these?
SELECT * FROM posts WHERE tags @> ARRAY['ruby', 'web'];

-- && overlap — do the arrays share ANY element?
SELECT * FROM posts WHERE tags && ARRAY['tech', 'news'];

-- access by index (1-based!) and length
SELECT tags[1], array_length(tags, 1) FROM posts;

-- unnest — expand an array into rows
SELECT id, unnest(tags) AS tag FROM posts;   -- one row per tag
```

`ANY`（値を含む）、`@>`（包含）、`&&`（重複）などの演算子、および`unnest`（行に展開）、`array_agg`（行を配列に集約）などの関数により、配列をクエリ可能にします。

## 配列の索引付け（GIN）

```sql
-- a GIN index makes array containment/membership queries fast
CREATE INDEX idx_posts_tags ON posts USING GIN (tags);
-- now WHERE tags @> ARRAY['ruby'] uses the index
```

## 配列を使用する場合（および使用しない場合）

```text
✓ USE for: simple lists tightly coupled to the row (tags, roles, a few scores)
  where you don't need to query/join the individual values much
✗ AVOID when: you need to query, join, or maintain the values relationally,
  or the list is large/complex → a separate related table (normalized) is better
→ Arrays are convenient but can violate normalization; use them judiciously.
```

## なぜ重要なのか

配列列はPostgreSQLの特徴的で有用な機能であり、それらを理解することはPostgresの機能を活用し、適切な設計判断を下すために重要です。

配列により、別のテーブルなしで**単一列に複数の値**（タグ、ロール、リスト）を保存できます — 行と密接に関連する単純なリストに便利です。

配列を効果的に使用するために必要なのは、配列を定義、挿入、特に**クエリ実行**する方法の理解です（メンバーシップのための`ANY`、包含のための`@>`、重複のための`&&`などの演算子、および配列を行に展開する`unnest`などの関数）。また、**GIN索引**により配列クエリが効率的になることを知ることはパフォーマンスにとって重要です。

同等に重要なのは、配列と正規化された関連テーブルのいずれを使用するかについての**設計判断**です。配列は、クエリ、結合、または関連的な管理が必要ない単純なリストには便利ですが、正規化原則に違反する可能性があり、個々の値をクエリしたり、結合したり、複雑な/大規模なリストを管理したりする必要がある場合は厄介になります — その場合、別の関連テーブルが優れた正規化された選択肢です。

このトレードオフを理解する（単純な結合されたリストの便宜性のための配列、関連的に管理されたデータのための別のテーブル）ことは、適切な設計判断を反映しています。

配列は有用でPostgresの特徴的な機能で、特定の設計を簡潔にできる（単純なリストの結合テーブルを回避）一方で、誤用される可能性があります（関連的であるべきデータを非正規化）。配列列を理解することは — それらをどのように定義、クエリ実行、索引付けするか、そして重要なことに、いつそれらが適切かと、いつ正規化されたテーブルがより良いか — 多値データの各種類に対して適切なアプローチを使用するPostgresスキーマを設計するために実用的で関連性のある知識です。