Devo alguma vez DELETE (SQL e DB) alguma coisa?

Question

Estou curioso, devo excluir alguma coisa? No momento, estou criando um site (para mim) que permite que você se inscreva em usuários e receba uma mensagem toda vez que o usuário fizer upload de conteúdo.

Ou comentários, se houver um tópico e alguém escrever um comentário direto ao seu comentário, você receberá uma mensagem dizendo isso. Devo deletá-los ou simplesmente escondê-los?

Cada assinatura tem três (64 bits) int. id, commentId, recipientId. Você pode descobrir quem escreveu para você olhando para a tabela de comentários via commentId. Se eu não usar delete, ele terá um quarto int dizendo o status (show, hidden / delete).

Devo deixá-los ou excluí-los? Se eu deveria deletá-los, então por quê? Eu posso ver, talvez, quando há um usuário pessoal que você deve excluir a pedido, mas outro que eu deveria excluir?

Eu não sei qual SQL DB vou usar.

-edit -

Obrigado pessoal. No momento, não vou excluir nada, exceto as coisas que posso gerar. Tal como essa coisa de assinatura sobre.

    

Answer 1

A empresa para a qual trabalho oferece software para pessoas em determinados setores regulamentados, de modo que geralmente tenho a atitude "nunca excluir qualquer " porque, se você excluir qualquer coisa, perderá a integridade da sua trilha de auditoria. Em vez disso, marque as informações como excluídas (ou mova-as para uma versão de archive das tabelas) e registre quem as "excluiu" e quando.

As únicas razões para realmente apagar coisas são

• se você estiver com pouco espaço (mas o disco é barato atualmente)
• para eficiência (mas se a sua estrutura de dados estiver bem indexada e não estiver muito fragmentada, isso fará pouca diferença)
• por motivos legais (se você for solicitado a remover os detalhes de alguém que provavelmente terá de cumprir, dependendo das leis locais de proteção de dados ou se o próprio conteúdo violar alguma lei)

Seus usuários podem estar agradecidos por nada ser realmente excluído, se eles acidentalmente excluírem algo útil e você puder recuperá-lo. E se um usuário aborrecido que forneceu anteriormente informações valiosas para o site lançar um chiado e excluir todos os seus posts em vingança, você pode retirar as exclusões facilmente.

Um ponto extra muito importante: você deve deixar claro em seus termos de serviço que as informações podem não ser realmente excluídas quando o usuário não pode mais vê-las e fornecer uma rota (se apenas "email x @ xx e pergunte para que seja feito ") para que eles realmente apaguem os dados, eles têm o direito sob as leis relevantes de pedir para serem excluídos.

    

Answer 2

Normalmente, os tamanhos modernos de disco e o desempenho de E / S significam que você não tem para excluir registros para economizar espaço ou manter o desempenho. Normalmente, um campo "registro excluído" no registro pode marcar o registro como excluído (ou como outro status) com uma trilha de auditoria.

Algumas indústrias exigem que você nunca exclua dados "transacionais" por motivos regulamentares. Você já sabe se precisa fazer isso. Se houver alguma informação de pagamento, você normalmente precisará manter os dados (ou disponibilizar os dados) por 7 anos (lei contábil do Reino Unido).

Para outros fins, há realmente um bom motivo para excluir dados fisicamente.

Se não estiver lá, não será detectável.

A Lei de Liberdade de Informação (no Reino Unido) declara que, se os dados forem detectáveis, eles serão incluídos no escopo de qualquer pesquisa. Isso inclui registros "suaves" e backups históricos.

Para alguns sistemas, garantimos que PURGARemos registros antigos e reutilizar / destruir fitas / arquivos de backup antigos após "tantos" meses para garantir que ele não esteja disponível para solicitações de FOI. (Atender a uma solicitação de FOI que remonta a vários anos e requer a restauração de centenas de caixas de correio antigas de backups de archive é MUITO onerosa).

Isso é diferente dos backups OPERACIONAIS. Nós mantemos backups para que possamos restaurar em caso de desastre. Também temos uma "Loja de Registros" para mídia impressa e eletrônica que DEVE ser mantida, e copiamos e-mails e coisas assim para aquela loja.

    

Answer 3

Meu instinto é nunca apagar nada. Você nunca sabe quando pode precisar. Se por algum motivo eu tiver que remover dados das tabelas de trabalho, tento movê-los para uma tabela de arquivos.

Tendo dito isso, isso pode ser um exagero se forem dados para seu próprio uso e é inconcebível que haja algum motivo legal para ver dados antigos. Você não diz muito sobre o seu aplicativo, mas um usuário poderia exigir a exibição de dados antigos, pois outro uso os libera?

JR

    

Answer 4

A exclusão ou não depende da quantidade de recursos que você tem disponível e da quantidade de dados que você coletará. Eu trabalhei em projetos antes de excluir exclusões. Significa apenas que todos os itens de dados terão uma data de início e uma data de término. O item de dados seria válido durante esse período, não antes, não depois. Assim, você poderia "excluir" algo definindo a data final como hoje.
Infelizmente, isso também significa que você teria que verificar a data atual com esse período para cada item de dados que deseja selecionar. Com o SQL, isso exigiria uma condição adicional às suas consultas.
Na verdade, para piorar as coisas, você pode até mesmo considerar a desativação das edições. Quando um item de dados é editado, basta definir a data final para agora e criar um novo item de dados com as mesmas chaves e as modificações. Dessa forma, você coletará uma enorme coleção de dados, mas será muito histórica e nada será excluído. Nesse caso, as datas de início / término também devem conter um componente de horário. (E você precisa se preocupar com o horário de verão quando os relógios são invertidos uma hora.) Mas, basicamente, o seu sistema só inseria novos itens, não modificava ou excluía nada.

    

Answer 5

Você tem que decidir se vale a pena salvar seus dados para sempre! Todos dizem que o disco é barato, mas isso não é toda a verdade. Depende da sua solução de armazenamento e do seu ambiente.

Se você usar discos fibre channel em uma SAN e não tiver mais espaço em disco, não será mais barato quando precisar adicionar outra diskarray devido à falta de espaço em sua matriz.

No seu caso, não parece que você esteja armazenando uma grande quantidade de dados, e o espaço em disco pode não ser um problema, mas qual é a relevância dos seus dados em 10 anos?

Outra coisa a considerar é o desempenho geral, não apenas o espaço em disco. Eu acho que é uma boa idéia armazenar dados históricos em outra tabela ou mesmo em outro banco de dados. Desta forma, eu terei menos manutenção, etc. Eu sei, existem outras soluções para arquivar dados históricos, como particionamento, mas se seus dados não são usados regularmente, por que implementar mais complexidade?

Eu tenho trabalhado em grandes bancos de dados nos últimos 6 anos e a estratégia de indexação é crusial quando você tem uma tabela com 500.000.000 registros. :) Se a sua consulta estiver usando uma busca de índice, mas o índice não contiver todos os dados necessários, será usada uma pesquisa de índice em cluster para cada registro encontrado no índice. Vamos dizer que você recebe 10% da tabela, você vai acabar com 50 000 000 de pesquisa de índice em cluster, e isso não é barato em tudo. Não lhe custa dinheiro, mas lhe custará desempenho.

/ Håkan Winther

    

Answer 6

Razões pelas quais você não deve excluir algo:

1. Você pode querer mais tarde

Razões pelas quais você deve excluir algo:

1. Você deseja garantir que nenhuma pessoa não autorizada possa lê-lo novamente (por exemplo, um número de cartão de crédito armazenado: se você apagá-lo, um intruso não poderá obtê-lo)
2. Você deseja garantir que as informações não possam ser solicitadas por você (por exemplo, por meio de solicitações da Lei de Liberdade de Informação)
3. Você deseja manter o tamanho dos dados pequeno por motivos de espaço ou velocidade (a indexação e o particionamento adequados podem ajudar com a questão da velocidade).
4. Você precisa excluí-lo por lei (por exemplo, leis de privacidade).

É sempre um trade-off, mas as implicações legais de manter muitos dados são importantes. Privacidade e segurança são coisas muitas vezes esquecidas nos dias de hoje. O desempenho real do banco de dados pode não exigir a exclusão de dados, a menos que os conjuntos de dados sejam enormes. Mesmo uma tabela com milhões de linhas e dezenas de colunas pode não precisar ser excluída se você particioná-la adequadamente e garantir que suas consultas sempre usem as partições adequadas. Quanto a um mandado ou solicitação FOIA solicitando dados armazenados, apenas você pode decidir como se sente e como seus clientes se sentem. Um dos motivos pelos quais limito o uso do Gmail é justamente esse o motivo: meus dados são armazenados nos EUA (estou no Canadá) e as agências dos EUA podem acessar até mesmo meus e-mails excluídos.

Tenha também em mente que as leis de privacidade, segurança e FOIA variam de país para país; você precisa estar ciente dessas leis em todos os países em que opera. Talvez se seus servidores estiverem em um país que limita o alcance de leis estrangeiras, mas talvez não. Consulte um advogado se seus dados forem confidenciais.

    

Answer 7

A pergunta que você realmente deve se fazer é: o custo de manter os dados (aumento dos custos de armazenamento, responsabilidade de manter dados que podem ser excluídos) é mais barato que o custo de excluir os dados? consulta de exclusão, responsabilidade de excluir dados que precisam ser mantidos e a possibilidade de tempo de inatividade ou desempenho reduzido devido à execução da consulta de exclusão)? O que for mais barato, vá em frente.

    

Answer 8

Um caso em que posso ver o arquivamento off-line e / ou a exclusão de dados é quando você executa uma consulta OLAP para resumir dados e armazená-los em uma tabela de resumo.

Estatísticas mensais do website são um ótimo exemplo disso. Depois de gerar várias visualizações de página para junho de 2009, isso nunca mudará. E é mais rápido adicionar todas as exibições de página da tabela de resumo e, em seguida, verificar a tabela que contém as transações on-line do mês atual, do que verificar os registros de um ano inteiro e gerar um relatório totalmente on-line. .

Se fosse eu, eu certamente copiaria a tabela on-line para 'june 2009', executaria a consulta de resumo e salvaria os dados na tabela de resumo e, em seguida, arquivaria a tabela on-line copiada antes de excluir todos entradas da tabela on-line original. Mas também sou um pouco paranóico!

Geralmente, em qualquer lugar em que seja mais eficiente usar o OLAP para gerar um resumo em relação a dados estáticos a partir desse ponto, é possível arquivar / excluir dados antigos. Caso contrário, não, eu uso um sistema de sinalização de exclusão para evitar a quebra da integridade relacional com meus sistemas de registro de atividades tipicamente extensos.