Não tenho certeza se/como devo postar isso ... Mas no caso de alguns seguirem DBA, mas não SO ...
Existe um meio geralmente aceito de gerenciar linhas ativas e não ativas em um ambiente controlado por versão de linha? E se não, o que você tentou e foi razoavelmente bem-sucedido?
(Detalhes completos no tópico SO ).
Estou pensando em implementar o controle de versão de objeto com o toque adicional de precisar ter objetos ativos e de rascunho, e poderia usar os insights de alguém com experiência nisso, pois estou começando a me perguntar se isso é possível sem hacks potencialmente horríveis.
Vou dividir em postagens com tags para fins de exemplo, mas meu caso de uso é um pouco mais geral (envolvendo dimensões que mudam lentamente - http://en.wikipedia.org/wiki/Slowly_change_dimension ).
Suponha que você tenha uma tabela de posts, uma tabela de tags e uma tabela post2tag:
posts (
id
)
tags (
id
)
post2tag (
post_id fkey posts(id),
tag_id fkey tags(id)
)
Estou precisando de algumas coisas:
- Ser capaz de mostrar exatamente como uma postagem parecia em uma data e hora arbitrárias, inclusive para linhas excluídas.
- Acompanhe quem está editando o quê, para uma trilha de auditoria completa.
- Precisa de um conjunto de visualizações materializadas (tabelas "ativas") para manter a integridade referencial (ou seja, o registro deve ser transparente para os desenvolvedores).
- Precisa ser adequadamente rápido para as linhas de rascunho ao vivo e mais recentes.
- Ser capaz de coexistir uma postagem de rascunho com uma postagem ativa.
Tenho investigado várias opções. Até agora, o melhor que encontrei (sem os pontos #4/#5) se parece um pouco com a configuração híbrida SCD type6, mas em vez de ter um booleano atual, há uma visualização materializada para a linha atual. Para todos os efeitos, é assim:
posts (
id pkey,
public,
created_at,
updated_at,
updated_by
)
post_revs (
id,
rev pkey,
public,
created_at,
created_by,
deleted_at
)
tags (
id pkey,
public,
created_at,
updated_at,
updated_by
)
tag_revs (
id,
public,
rev pkey,
created_at,
created_by,
deleted_at
)
post2tag (
post_id fkey posts(id),
tag_id fkey tags(id),
public,
created_at,
updated_at,
updated_by
)
post2tag_revs (
post_id,
tag_id,
post_rev fkey post_revs(rev), -- the rev when the relation started
tag_rev fkey tag_revs(rev), -- the rev when the relation started
public,
created_at,
created_by,
deleted_at,
pkey (post_rev, tag_rev)
)
Estou usando pg_temporal para manter índices no period(created_at, deleted_at). E mantenho as várias tabelas sincronizadas usando gatilhos. Yada yada yada... Criei os gatilhos que permitem cancelar uma edição de postagens/tags de forma que o rascunho seja armazenado nas rotações sem ser publicado. Funciona muito bem.
Exceto quando preciso me preocupar com as relações relacionadas à linha de rascunho em post2tag. Nesse caso, o inferno começa, e isso me indica que tenho algum tipo de problema de design aí. Mas estou ficando sem ideias...
Eu considerei a introdução de duplicação de dados (ou seja, linhas post2tag introduzidas para cada revisão de rascunho). Isso funciona, mas tende a ser muito mais lento do que eu gostaria.
Eu considerei introduzir tabelas de rascunhos para o "último rascunho", mas isso rapidamente tende a se tornar muito, muito feio.
Eu considerei todos os tipos de bandeiras...
Portanto, pergunte: existe um meio geralmente aceito de gerenciar linhas ativas e não ativas em um ambiente controlado por versão de linha? E se não, o que você tentou e foi razoavelmente bem-sucedido?
Publicação cruzada da resposta também:
Acho que acertei. Basicamente, você adiciona um campo de rascunho (único) às tabelas relevantes e trabalha nos rascunhos como se fossem um novo post/tag/etc.: