bluenote10's questions

Vamos supor um cenário com as entidades Persone Companyuma tabela PersonCompanyStocksque modela quantas ações uma pessoa possui de uma determinada empresa (cardinalidade N:M). Por exemplo:

person | company | num_stocks
-----------------------------
Alice  | foo     | 300
Bob    | foo     | 100
Bob    | bar     | 200

Esta tabela usa (person, company)como chave primária para garantir entradas exclusivas e chaves estrangeiras para a respectiva tabela pessoa/empresa (estou usando apenas IDs de string para simplificar).

Agora vamos supor que a empresa barcompra a empresa foo. Queremos atualizar a tabela de forma que ela se torne:

person | company | num_stocks
-----------------------------
Alice  | bar     | 300
Bob    | bar     | 300

Observar apenas Aliceo registro de 's sugere usar uma abordagem ingênua como:

UPDATE
  PersonCompanyStocks
SET
  company = "bar"
WHERE
  company = "foo"

No entanto, esta atualização falha duplicate key value violates unique constraint ...porque Bobjá existe uma linha com a chave ("Bob", "bar"). INSERTO Postgres de For suporta ON CONFLICT DO ..., mas parece que não há equivalente para UPDATE. E claramente também temos que lidar com a fusão adequada do num_stockvalor das duas linhas.

Qual é a melhor estratégia para abordar este problema? Eu só vejo uma solução relativamente feia:

• Uma consulta para determinar as duplicatas.
• Um UPDATEpara mesclar as duplicatas na linha final.
• Um DELETEpara remover as duplicatas ofensivas.
• O acima UPDATEpara fazer a renomeação em linhas sem duplicatas.

Isso parece complexo e provavelmente é propenso a condições de corrida. O Postgres oferece algum truque para resolver isso de forma mais elegante?

Faz muito tempo que não estudei design relacional, mas tinha uma vaga lembrança de que isso me incentivava a não dividir uma tabela desnecessariamente. Por exemplo, dadas as dependências funcionais

K -> A
K -> B
K -> C

minha suposição era que o "melhor" esquema é justo {KABC}e não algo como {KAB, KC}ou mesmo {KA, KB, KC}. Pelo menos na prática é assim que eu vi os designers de banco de dados implementarem a tabela.

No entanto, uma rápida atualização na Wikipedia indica que o formalismo de normalização

• não faz nenhuma declaração no sentido de obter um "esquema mínimo",
• 6NF exigiria mesmo {KA, KB, KC}. Uma vez que 6NF implica as outras formas normais, isso implica que é mesmo impossível para eles fazerem um requisito mínimo.

Estou um pouco confuso que eu tenho isso errado o tempo todo. A noção de "obter um número mínimo de tabelas" realmente não desempenha nenhum papel no design relacional formal e é apenas uma prática comum?