Digamos que temos duas tabelas usere book.

No nível do aplicativo, para garantir a integridade dos dados e evitar condições de corrida, bloqueamos a entidade no início da transação.

Questão 1:

Digamos que no nível do aplicativo temos duas solicitações em execução ao mesmo tempo:

Solicitação 1 (nível do aplicativo):

start trx
lock for update user with id 1
lock for update book with id 2
do changes
commit

Solicitação 2 (nível do aplicativo):

start trx
lock for update book with id 2
lock for update user with id 1
do changes
commit

Pode acontecer que ambos os primeiros bloqueios da solicitação sejam aplicados antes dos segundos bloqueios, solicitação de 1 bloqueio do usuário 1 e solicitação de 2 bloqueios do livro 2, o que resultará em bloqueio morto.

Como podemos evitar isso? Minha única idéia é escrever em algum lugar uma ordem de bloqueio para todas as tabelas user->booke garantir que a sigamos.

Questão 2:

Se fizermos duas consultas como essa em solicitações diferentes para bloquear entidades antes da mutação

• Solicitação 1SELECT * FROM user WHERE id IN [1,2] FOR UPDATE
• Solicitação 2SELECT * FROM user WHERE id IN [2,1] FOR UPDATE

Isso pode resultar em impasse? Por exemplo, se UMA consulta por algum motivo bloquear o usuário 1 primeiro e depois mudar para a solicitação 2 e depois voltar para bloquear o usuário 2.

Vamos supor que temos o seguinte banco de dados:

Ou no formato pseudo sql (todas as colunas não são nulas):

create table road (
  id int PK
) 
create table item_on_road (
  id int PK
  road_id int FK road.id
  position_order int
  UNIQUE (road_id, position_order)
)
create table rock (
  id int PK FK item_on_road.id
  size float
)
// and so on

Temos um roadno qual podemos viajar em uma direção.

Ao longo da estrada podemos encontrar coisas diferentes item_on_roadpara encontrá-las position_ordercomo1,2,3

As coisas que encontramos na estrada podem ser diferentes, de signa gas_station.

Agora gostaria de fazer uma pergunta:

1. Este design de banco de dados corresponde às formas normais do 1º ao 5º banco de dados? Eu diria que não, porque podemos criar item_on_roadentradas sem correspondênciarock

2. Se não corresponder à 5ª forma normal, como fazer?

Perguntas opcionais:

3. Se a resposta a uma pergunta for sim, como garantir a existência do rockcaso item_on_roadcriado?

4. Se a resposta a uma pergunta for sim, como garantir que não podemos criar rocke signapontar para o mesmo ID?

Digamos que decidimos dividir usera tabela em duas, uma terá dados relacionados à autenticação, outra descrição básica do usuário:

   user_table
user_id | name
1       | Max
2       | Alex
3       | Should not be possible

   auth_table
user_id | email   | password
1       | [email protected] | 123
2       | [email protected] | 321
4       | [email protected] | Should not be possible

É possível impor a existência do mesmo user_id? Basicamente, ambas as tabelas devem ter exatamente o mesmo número de linhas e cada linha deve ter uma correspondência em ambas as tabelas.

Eu quero que a tabela contenha logs e seja em loop, então, quando chegar a última chave na sequência, ela começará de um e reescreverá os logs antigos.

Eu posso fazer isso se eu marcar a sequência como ciclo e fizer solicitações assim:

INSERT INTO logs (initiator_id, target_id, action, message) VALUES ($1, $2, $3, $4)
ON CONFLICT (id) DO UPDATE SET target_id=$2, initiator_id=$1, action=$3, message=$4;

O que eu não gosto, é que eu preciso repetir as mesmas inserções se houver conflito (linha 2)

O que estou curioso, é uma boa maneira de fazer, ou há outras maneiras mais práticas para tabelas que você precisa limpar, digamos, a cada 3 montagens?

Ou talvez haja uma maneira de gerar id exclusivo sem usar sequências?

Por enquanto eu decidi fazer 2 colunas de chave primária (data, initiator_id) como log é sempre 1 ação de cada vez.