Dicas sobre refatoração um esquema de banco de dados desatualizado [fechado]
https://stackoverflow.com/questions/104380
-
01-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Ser preso com um esquema de banco de dados legado que já não reflecte o seu modelo de dados é o pesadelo de cada desenvolvedor. No entanto, com toda a conversa de refatoração de código para manutenção eu não tenha ouvido falar muito de refatoração esquemas de banco de dados desatualizados.
Quais são algumas dicas sobre como fazer a transição para um esquema melhor sem quebrar todo o código que depende do antigo? Vou propor um problema específico que eu estou tendo para ilustrar meu ponto, mas fique à vontade para dar conselhos sobre outras técnicas que provaram útil -. Aqueles que provavelmente virá a calhar bem
Meu exemplo:
A minha empresa recebe e envia produtos. Agora um recibo produto e um embarque do produto ter alguns dados muito diferentes associados com eles, para os designers de banco de dados original criada uma tabela separada para as receitas e para as transferências.
Em meu um ano trabalhando com este sistema Eu vim à conclusão de que o esquema atual não faz um pingo de sentido. Afinal, um recibo e uma expedição são basicamente uma transação, cada um deles envolvem alterando a quantidade de um produto, no fundo apenas o sinal +/- é diferente. De fato, freqüentemente precisa encontrar o montante total que o produto mudou ao longo de um período de tempo, um problema para o qual este projeto é francamente intratável.
Obviamente o design adequado seria ter uma única tabela Transações com o Id ser uma chave estrangeira de qualquer um ReceiptInfo ou uma tabela ShipmentInfo. Infelizmente, o esquema errado já está em produção há alguns anos e tem centenas de procedimentos armazenados e milhares de linhas de código escrito fora dele. Como então eu posso transição do esquema para o trabalho corretamente?
Solução
Aqui está um catálogo inteiro de refatorações de banco de dados:
Outras dicas
Isso é uma coisa muito difícil de trabalhar ao redor; Um casal rápidas opções depois de refatoração do banco de dados são:
Este livro (Refactoring Databases) foi um Deus-send para me quando se lida com esquemas de banco de dados legado, inclusive quando eu tive que lidar com quase exatamente o mesmo problema para o nosso banco de dados de inventário.
Além disso, ter um sistema em vigor para rastrear alterações no esquema de banco de dados (como uma série de scripts alter que é armazenado int repositório ele controle de origem) ajuda imensamente em descobrir dependências de código-a-banco de dados.
Os procedimentos armazenados e vistas são seu amigo aqui. Mesmo se o sistema não usá-los, alterá-lo para usá-los, em seguida, refatorar o debaixo de banco de dados.
Seus recibos e embarques, em seguida, tornar-se pontos de vista.
Cuidado, recibos e embarques são realmente dois animais muito diferentes na maioria dos sistemas com quem trabalhei. Recibos estão ligados a fornecedores, enquanto as vendas estão ligadas a clientes (ou cliente / ship-to locais). Ao nível de estoque, eles são muitas vezes representado o mesmo.
Todos os acessos de dados limitado a procedimentos armazenados? Caso contrário, a tarefa poderia ser quase impossível. Se assim for, você apenas tem que certificar-se de seus scripts de migração de dados funcionam bem a transição do velho para o novo esquema, e certifique-se os procedimentos armazenados honrar theur entradas e saídas.
Esperamos que nenhum deles "SELECT *" consultas. Se eles fizerem isso, use 'tablename sp_help' para obter a lista completa das colunas, copie isso e substituir cada * com a lista coluna completa, só para ter certeza que você não quebrar o código do cliente.
Eu recomendaria fazer as mudanças gradualmente, e fazer um monte de testes de integração. É difícil fazer uma remodelação significativa sem a introdução de alguns bugs.
A primeira coisa é criar o esquema de tabela. Eu já fiz isso para um banco de dados legada utilizando Enterprise Architect. Você pode selecionar o DB e vai criar-lhe a cada tabelas / campos. Então, você vai precisar dividir tudo em categorias. Exemple toda a sua recebe e envia produtos juntos, coisas cliente em uma outra categoria. Depois que tudo estiver claro, você será capaz de refatorar campo, criando nova tabela, nova releashionship e novos campos. Claro, isso terá muitas mudanças se tudo é acessado sem procedimento armazenado.
Eu não acho que é óbvio que o ID da tabela de transações deve ser uma chave estrangeira para tanto ReceiptInfo ou um ShipmentInfo. Pense o contrário. Em um modelo orientado a objeto, você deve ter uma tabela de transação eo ReceiptInfo ou um ShipmentInfo deve ter uma chave estrangeira para a tabela de transação. Se você tiver sorte, haverá apenas 1 ou 2 pontos no código onde os novos registros em ReceiptInfo ou um ShipmentInfo são feitas. Lá você deve adicionar código onde você adicionar uma entrada na tabela de Transação e depois que criar a entrada em ReceiptInfo ou ShipmentInfo com a chave estrangeira para Transaction.
Às vezes, você pode criar novas tabelas que têm melhores estruturas e, em seguida, criar pontos de vista com os nomes de seus antigos tabelas, mas são baseados nos dados nas novas tabelas. Dessa forma, você código doesnt pausa enquanto você começa a mover-se para uma estrutura melhor. Tenha cuidado com thsi embora como às vezes você se move de uma tabela não-relacional para uma estrutura relacional onde você tem vários registros enquanto o código estará esperando apenas um. Esta é particulalry verdadeiro se você tem desenvolvedores que usam subconsultas.
Em seguida, à medida que cada coisa é alterada, ele vai afastar-se as vistas para a mesa real. Eventualmente, você pode soltar os pontos de vista. Esta, pelo menos, permite que você trabalhe de forma incremental para manter as coisas funcionando como você se move coisas, mas começar a consertar as coisas para usar um projeto melhor.
