`Bandeira ativo' ou não?

Question

OK, então praticamente toda aplicação baseada banco de dados tem que lidar com registros "não activos". Ou, soft-supressões ou marcação algo como "para ser ignorado". Estou curioso para saber se existem alternativas pensamentos radicais sobre uma coluna `ativa'(ou uma coluna de status).

Por exemplo, se eu tinha uma lista de pessoas

CREATE TABLE people (
  id       INTEGER PRIMARY KEY,
  name     VARCHAR(100),
  active   BOOLEAN,
  ...
);

Isso meios para obter uma lista de pessoas ativas, você precisa usar

SELECT * FROM people WHERE active=True;

Alguém sugerem que os registros não ativos seria movido fora de uma tabela separada e onde apropriado um UNION é feito para se juntar os dois?

A curiosidade impressionante ...

EDIT: eu deveria deixar claro, eu estou voltando para isso de uma perspectiva purista. Eu posso ver como arquivamento de dados pode ser necessário para grandes quantidades de dados, mas isso não é onde eu estou vindo. Se você fizer um * SELECT FROM pessoas não faria sentido para mim que as entradas estão em um sentido "ativo"

Graças

Answer 1

Você particionar a tabela na bandeira ativa, de modo que os registros ativos estão em uma partição, e registros inativos estão na outra partição. Em seguida, você cria um modo de exibição ativo para cada tabela que tem automaticamente o filtro ativo nele. O mecanismo de consulta de banco de dados restringe automaticamente a consulta para a partição que tem os registros ativos na mesma, o que é muito mais rápido do que até mesmo usando um índice em que a bandeira.

Aqui está um exemplo de como criar uma tabela de partição em Oracle. Oracle não tem tipos de colunas boolean, para que eu tenha modificado a estrutura da tabela para fins Oracle.

CREATE TABLE people
(
   id       NUMBER(10),
   name     VARCHAR2(100),
   active   NUMBER(1)
)
PARTITION BY LIST(active)
(
   PARTITION active_records VALUES (0)
   PARTITION inactive_records VALUES (1)
);

Se você quiser você pode colocar cada partição em diferentes espaços de tabela. Você também pode particionar seus índices também.

Aliás, esta parece uma repetição do este pergunta, como um novato eu preciso perguntar, qual é o procedimento sobre como lidar com duplicatas não intencionais?

Editar: Conforme solicitado nos comentários, forneceu um exemplo para a criação de uma tabela particionada no Oracle

Answer 2

Bem, para garantir que você só desenhar registos activos na maioria das situações, você pode criar visualizações que contêm apenas os registros ativos. Dessa forma, é muito mais fácil de não deixar de fora a parte ativa.

Answer 3

Nós usamos uma enumeração ( 'ativo', 'inativa', 'excluídos') na maioria das mesas, e nós realmente temos uma bandeira 3-way. Eu acho que funciona bem para nós em diferentes situações. Sua milhagem pode variar.

Answer 4

Movendo coisas inativa é geralmente uma idéia estúpida. É um monte de sobrecarga com muito potencial para erros, tudo se torna mais complicado, como desarmazenando o material etc. O que você faz com os dados relacionados? Se você mover tudo isso, também, você tem que modificar cada consulta individual. Se você não movê-lo, que vantagem você estava esperando para começar?

que leva ao próximo ponto: por que você movê-lo? Uma tabela corretamente indexadas requer uma pesquisa adicional quando as duplas de tamanho. Qualquer melhoria de desempenho é obrigado a ser insignificante. E por que você sequer pensar nisso até que o tempo futuro distante quando você realmente tem problemas de desempenho?

Answer 5

Eu acho que olhando para ele estritamente como um pedaço de dados, então o caminho que é mostrado no post original é adequada. A peça flag ativa de dados é directamente dependente da chave primária e deve estar em cima da mesa.

Essa tabela contém dados sobre as pessoas, independentemente do estado actual dos seus dados.

Answer 6

A bandeira ativo é uma espécie de feio, mas é simples e funciona bem.

Você pode movê-los para outra mesa como você sugeriu. Eu sugiro a olhar para o percentual de registros de ativos / inativos. Se você tiver mais de 20 ou 30% de registros inativos, então você pode considerar que se deslocam-los em outro lugar. Caso contrário, não é um grande negócio.

Answer 7

Sim, nós o faria. Atualmente, temos os "= ativos 'T / F'" coluna em muitas das nossas mesas, principalmente para mostrar a linha 'mais recente'. Quando uma nova linha é inserida, a linha T anterior é marcado F para mantê-lo para fins de auditoria.

Agora, estamos nos movendo para uma abordagem 2-mesa, quando uma nova linha é inserida, a linha anterior é movido para uma tabela de histórico. Isso nos dará um melhor desempenho para a maioria dos casos -. Olhando para os dados atuais

O custo é um pouco mais do que o método antigo, anteriormente, que teve de atualização e inserção, agora você tem que inserir e atualizar (ou seja, em vez de inserir uma nova linha T, modificará a linha existente com todos os novos dados), por isso o custo é apenas o de passar em toda uma linha de dados em vez de passar em apenas as alterações. Isso dificilmente vai fazer qualquer efeito.

O benefício de desempenho é que indexar o seu principal da mesa é significativamente menor, e você pode otimizar seus espaços de tabela melhor (eles não vão crescer bastante tanto!)

Answer 8

bandeiras binários como este no seu esquema são uma ideia BAD. Considere a consulta

SELECT count(*) FROM users WHERE active=1

Parece bastante simples. Mas o que acontece quando você tem um grande número de usuários, tantos que a adição de um índice para esta tabela seria necessário. Mais uma vez, parece simples

ALTER TABLE users ADD INDEX index_users_on_active (active)

EXCETO !! Este índice é inútil porque a cardinalidade desta coluna é exatamente dois! Qualquer otimizador de consulta de banco de dados irá ignorar este índice porque ele é de baixa cardinalidade e fazer uma varredura da tabela.

Antes de encher o seu esquema com votos bandeiras considerar como você está indo para o acesso a esses dados.

https://stackoverflow.com/questions/108503/mysql-advisable-number -de-fileiras

Answer 9

Nós usamos bandeiras ativos com bastante frequência. Se seu banco de dados vai ser muito grande, eu podia ver o valor na migração valores inativos para uma tabela separada, no entanto.

Você, então, requerem apenas uma união das mesas quando alguém quer ver todos os registros, ativos ou inativos.

Answer 10

Na maioria dos casos, um campo indicando eliminação binário é suficiente. Muitas vezes há um mecanismo a limpeza que irá remover esses registros excluídos depois de um determinado período de tempo, então você pode querer começar o esquema com um timestamp excluída.

Answer 11

Afastando-se a uma mesa separada e trazê-los backup leva tempo. Dependendo de quantos registros ficar offline e quantas vezes você precisa trazê-los de volta, ele pode ou não ser uma boa idéia.

Se a maioria não voltar uma vez que eles estão enterrados, e são utilizados apenas para resumos / relatórios / o que quer, então ele vai fazer a sua tabela principal menor, consulta mais simples e provavelmente mais rápido.

Answer 12

Usamos dois métodos para lidar com registros inativos. O método que usamos é dependente da situação. Para registros que são essencialmente valores de pesquisa, usamos o campo de bits Ativo. Isso nos permite entradas Desativar para que eles não vão ser usados, mas também nos permite manter a integridade dos dados com as relações.

Nós usamos o "movimento para a mesa de separação" método onde os dados não é mais necessária e os dados não faz parte de uma relação.

Answer 13

A situação realmente dita solução, methinks:

Se a tabela contém os usuários, poderia ser usado, em seguida, vários campos "bandeira". Um para Deleted, etc. desativado ou se o espaço é um problema, então uma bandeira para deficientes seria suficiente, e então realmente apagar a linha se eles foram excluídos.

Também depende de políticas para armazenar dados. Se houver políticas para manter os dados arquivados, em seguida, uma tabela separada seria provavelmente necessário após qualquer grande período de tempo.

Answer 14

Não - isso é uma coisa muito comum - algumas variações, dependendo dos requisitos específicos (mas você já cobriu):

1) Se você espera ter um monte de dados - como vários terabytes ou mais - registros não é uma má idéia para arquivo apagados imediatamente - embora você pode usar uma abordagem de combinação de marcação como excluído, em seguida, copiar a tabelas de arquivo <. / p>

2) É claro que a opção de gravar uma exclusão dura ainda existe - embora nós desenvolvedores tendem a ser dados embalar-ratos - Eu sugiro que você deve olhar para o processo de negócio e decidir se existe agora qualquer necessidade de ainda manter o dados - se houver - fazê-lo ... se não houver -. você provavelmente deve se sentir livre apenas para jogar o material afastado ..... novamente, de acordo com o cenário de negócios específica

Answer 15

A partir de uma 'perspectiva purista' o modelo realtional não diferencia entre uma visão e uma mesa - ambos são relações. Assim que o uso de uma exibição que usa o discriminador é perfeitamente significativa e válida desde que as entidades são corretamente chamado por exemplo Pessoa / ActivePerson.

Além disso, a partir de uma 'perspectiva purista' a tabela deve ser nomeado pessoa, não pessoas como o nome da relação reflete uma tupla, não todo o conjunto.

Answer 16

Em relação a indexação do boolean, por que não:

ALTER TABLE users ADD INDEX index_users_on_active (id, active) ;  

que não iria melhorar a pesquisa?
No entanto, eu não sei o quanto de que a resposta depende da plataforma.