Como implementar um relacionamento muitos-para-muitos no PostgreSQL?

CREATE TABLE product (
  product_id serial PRIMARY KEY  -- implicit primary key constraint
, product    text NOT NULL
, price      numeric NOT NULL DEFAULT 0
);

CREATE TABLE bill (
  bill_id  serial PRIMARY KEY
, bill     text NOT NULL
, billdate date NOT NULL DEFAULT CURRENT_DATE
);

CREATE TABLE bill_product (
  bill_id    int REFERENCES bill (bill_id) ON UPDATE CASCADE ON DELETE CASCADE
, product_id int REFERENCES product (product_id) ON UPDATE CASCADE
, amount     numeric NOT NULL DEFAULT 1
, CONSTRAINT bill_product_pkey PRIMARY KEY (bill_id, product_id)  -- explicit pk
);

• 
  A relação n:m é normalmente implementado por uma tabela separada - bill_product nesse caso.
  
• 
  Eu adicionei serial colunas como chaves primárias substitutas . No Postgres 10 ou posterior, considere uma IDENTITY coluna em vez disso. Ver:
  
  • Renomeie tabelas com segurança usando colunas de chave primária serial
  • Coluna da tabela de incremento automático
  • https://www.2ndquadrant.com/en/blog/postgresql-10-identity-columns/
  
  Eu recomendo isso, porque o nome de um produto dificilmente é único (não é uma boa "chave natural"). Além disso, impor a exclusividade e fazer referência à coluna em chaves estrangeiras geralmente é mais barato com um integer de 4 bytes (ou mesmo um bigint de 8 bytes ) do que com uma string armazenada como text ou varchar .
  
• 
  Não use nomes de tipos de dados básicos como date como identificadores . Embora isso seja possível, é um estilo ruim e leva a erros e mensagens de erro confusos. Use identificadores legais, minúsculos e sem aspas. Nunca use palavras reservadas e evite identificadores de maiúsculas e minúsculas entre aspas duplas, se puder.
  
• 
  "nome" não é um bom nome. Renomeei a coluna da tabela product para ser product (ou product_name ou similar). Essa é uma convenção de nomenclatura melhor . Caso contrário, quando você junta algumas tabelas em uma consulta - o que você faz muito em um banco de dados relacional - você acaba com várias colunas chamadas "nome" e precisa usar aliases de coluna para resolver a bagunça. Isso não é útil. Outro antipadrão difundido seria apenas "id" como nome de coluna.
  Não tenho certeza de qual é o nome de uma bill seria. bill_id provavelmente será suficiente neste caso.
  
• 
  price é de tipo de dados numeric para armazenar números fracionários precisamente como digitados (tipo de precisão arbitrária em vez de tipo de ponto flutuante). Se você lida exclusivamente com números inteiros, torne esse integer . Por exemplo, você pode economizar preços como centavos .
  
• 
  A amount ("Products" na sua pergunta) vai para a tabela de vinculação bill_product e é do tipo numeric também. Novamente, integer se você lida exclusivamente com números inteiros.
  
• 
  Você vê as chaves estrangeiras em bill_product ? Eu criei ambos para cascata de mudanças:ON UPDATE CASCADE . Se um product_id ou bill_id deve mudar, a mudança é em cascata para todas as entradas dependentes em bill_product e nada quebra. Essas são apenas referências sem significado próprio.
  Eu também usei ON DELETE CASCADE para bill_id :Se uma fatura for excluída, seus detalhes morrerão com ela.
  Não é assim para produtos:você não deseja excluir um produto que é usado em uma fatura. O Postgres lançará um erro se você tentar isso. Você adicionaria outra coluna ao product para marcar linhas obsoletas ("exclusão reversível").
  
• 
  Todas as colunas neste exemplo básico acabam sendo NOT NULL , então NULL valores não são permitidos. (Sim, todos colunas - as colunas de chave primária são definidas UNIQUE NOT NULL automaticamente.) Isso porque NULL valores não fariam sentido em nenhuma das colunas. Facilita a vida de um iniciante. Mas você não vai escapar tão facilmente, você precisa entender NULL manipulação de qualquer maneira. Colunas adicionais podem permitir NULL valores, funções e junções podem introduzir NULL valores em consultas etc.
  
• 
  Leia o capítulo sobre CREATE TABLE no manual.
  
• 
  As chaves primárias são implementadas com um índice exclusivo nas colunas-chave, o que torna rápidas as consultas com condições na(s) coluna(s) PK. No entanto, a sequência de colunas de chave é relevante em chaves de várias colunas. Desde o PK em bill_product está em (bill_id, product_id) no meu exemplo, você pode querer adicionar outro índice apenas em product_id ou (product_id, bill_id) se você tiver dúvidas procurando por um determinado product_id e sem bill_id . Ver:
  
  • Chave primária composta PostgreSQL
  • Um índice composto também é bom para consultas no primeiro campo?
  • Trabalho de índices no PostgreSQL
• 
  Leia o capítulo sobre índices no manual.