As tabelas do AnalyticDB for PostgreSQL funcionam de forma semelhante às de bancos de dados relacionais, com uma diferença fundamental: as linhas são distribuídas entre os nós de computação. A política de distribuição de cada tabela define como essas linhas se espalham.
Crie uma tabela padrão
Use CREATE TABLE para definir uma tabela. Na criação, especifique:
Nomes das colunas e seus tipos de dados
Restrições
Sintaxe:
CREATE TABLE table_name (
[ { column_name data_type [ DEFAULT default_expr ] -- Column definition
[column_constraint [ ... ]] -- Column-level constraint
]
| table_constraint -- Table-level constraint
])
[ WITH ( storage_parameter=value [, ... ] ) ] -- Storage model
[ DISTRIBUTED BY (column, [ ... ] ) | DISTRIBUTED RANDOMLY ] -- Distribution key
[ partition clause] -- Partitioning strategy
Exemplo:
O exemplo a seguir cria uma tabela sales com trans_id como chave de distribuição e particionamento por intervalo de datas.
CREATE TABLE sales (
trans_id int,
date date,
amount decimal(9,2),
region text)
DISTRIBUTED BY (trans_id)
PARTITION BY RANGE(date)
(start (date '2018-01-01') inclusive
end (date '2019-01-01') exclusive every (interval '1 month'),
default partition outlying_dates);
Crie uma tabela temporária
Tabelas temporárias armazenam dados intermediários durante uma sessão ou transação. Por padrão, o sistema exclui automaticamente a tabela temporária ao final da sessão.
Sintaxe:
CREATE TEMPORARY TABLE table_name(...)
[ON COMMIT {PRESERVE ROWS | DELETE ROWS | DROP}]
Use a cláusula ON COMMIT para controlar o comportamento da tabela ao final da transação atual:
|
Opção |
Comportamento |
|
|
Mantém todas as linhas. Esta é a configuração padrão. |
|
|
Remove todas as linhas, mas preserva a estrutura da tabela. |
|
|
Exclua a tabela completamente. |
Exemplo:
CREATE TEMPORARY TABLE temp_foo (a int, b text) ON COMMIT DROP;
Definir restrições
As restrições limitam os dados armazenados em uma tabela no nível da coluna ou da própria tabela.
Antes de definir restrições, observe as regras a seguir:
Restrições
CHECKpodem referenciar apenas colunas da tabela onde foram definidas.Restrições
UNIQUEePRIMARY KEYdevem incluir a chave de distribuição. Essas restrições não são permitidas em tabelas com otimização de anexos (AO) ou orientadas a colunas.Restrições
FOREIGN KEYsão permitidas, mas não impostas.Uma restrição definida em uma partição aplica-se a todas as outras partições. Não é possível limitar o escopo das restrições a partições individuais.
Sintaxe:
UNIQUE ( column_name [, ... ] )
| PRIMARY KEY ( column_name [, ... ] )
| CHECK ( expression )
| FOREIGN KEY ( column_name [, ... ] )
REFERENCES table_name [ ( column_name [, ... ] ) ]
[ key_match_type ]
[ key_action ]
[ key_checking_mode ]
Restrições CHECK
Uma restrição CHECK exige que os valores da coluna atendam a uma expressão booleana.
CREATE TABLE products (
product_no integer,
name text,
price numeric CHECK (price > 0)
);
Restrições NOT NULL
A restrição NOT NULL impede que uma coluna contenha valores NULL.
CREATE TABLE products (
product_no integer NOT NULL,
name text NOT NULL,
price numeric
);
Restrições UNIQUE
A restrição UNIQUE garante que os valores em uma coluna ou grupo de colunas sejam exclusivos em todas as linhas. A tabela deve usar distribuição hash e as colunas da restrição precisam incluir a chave de distribuição.
CREATE TABLE products (
product_no integer UNIQUE,
name text,
price numeric)
DISTRIBUTED BY (product_no);
Restrições PRIMARY KEY
A restrição PRIMARY KEY combina uma restrição UNIQUE com uma restrição NOT NULL. A tabela deve ter distribuição hash e as colunas da restrição devem incluir a chave de distribuição.
Quando uma tabela possui chave primária, a coluna ou colunas correspondentes são usadas como chave de distribuição por padrão.
CREATE TABLE products (
product_no integer PRIMARY KEY,
name text,
price numeric)
DISTRIBUTED BY (product_no);