Quais são os nomes desses conceitos do Postgres?

Se você quiser nomes de teoria relacional , então:

1. Título (mas ninguém o chama assim, geralmente "nomes de campos" ou "nomes de atributos" ou "nomes de colunas" são mais típicos)
2. Tupla
3. Nome do Atributo
4. Atributo (mas isso vai confundir as pessoas)
5. Valor do atributo

... e um tipo de dados é um domínio . Toda a mesa é uma relação .

Ninguém realmente usa essa linguagem embora. Mais típico seria:

1. Definição de tabela (se incluir tipos de dados, restrições etc.) ou nomes de coluna , se não incluir .
2. Tupla ou linha
3. Nome do campo ou nome da coluna
4. Coluna (se incluir nome) ou valores de coluna (se não incluir ); mas o último é incomum em bancos de dados relacionais, pois você raramente faz referência a uma coluna, exceto selecionando campos de tuplas.
5. Valor do campo ou atributo

A coisa toda em conjunto é geralmente chamada de tabela , mas a relação também é bastante comum.

Quaisquer que sejam os nomes que você escolher usar, não assuma que as tuplas tenham qualquer ordem natural em uma relação . Eles não.

E não coloque a ordenação de colunas em sua API. A ordenação das colunas é estável em um resultado de consulta, é claro, mas os aplicativos devem ser desencorajados de codificar as posições ordinais das colunas. Tudo bem (pseudocódigo):

 zip(['col1', 'col2', 'col3'], do_query('SELECT col1, col2, col3 FROM my_table WHERE ...'))

mas esta é uma má, má ideia:

 zip(['col1', 'col2', 'col3'], do_query('SELECT * FROM my_table WHERE ...)]

pois qualquer adição de uma coluna quebrará o código. Assim como mudanças menos óbvias, como alterar o tipo de dados de uma coluna.

Os aplicativos devem ser incentivados a usar interfaces de consulta que produzem um mapa de nome de campo para valor como resultado, onde os nomes de campo são descobertos a partir dos metadados do conjunto de resultados.

Para eficiência, você ainda deseja oferecer acesso ordinal. Mas o acesso ao nome do campo geralmente é preferível.

Python, por exemplo, faz isso com um objeto de resultado que pode se comportar tanto como uma matriz (acesso ordinal) quanto como um dicionário (acesso de chave).

No entanto , você omitiu a digitação de dados . BDs relacionais são fortemente tipados.

Aqui está uma definição de tabela mais típica:

demo-> \d address
                                Table "public.address"
   Column    |  Type   |                          Modifiers                           
-------------+---------+--------------------------------------------------------------
 address_id  | integer | not null default nextval('address_address_id_seq'::regclass)
 customer_id | integer | not null
 address     | text    | 
Indexes:
    "address_pkey" PRIMARY KEY, btree (address_id)
Foreign-key constraints:
    "address_customer_id_fkey" FOREIGN KEY (customer_id) REFERENCES customer(customer_id)

Criticamente, observe que cada coluna tem um nome, um tipo e zero ou mais restrições como not nullou primary key. Há também vários outros detalhes, como restrições de chave estrangeira.

1. Cabeçalho
2. Fileira
3. Nome da coluna
4. Coluna
5. Valor (embora a coisa que contém o valor seja uma célula)