Este é um problema comum no design de banco de dados:a questão de separar ou "arquivar" registros que não estão mais "ativos".

As abordagens mais comuns são:

• Tudo em uma tabela, marque os pedidos como "completos" conforme apropriado. Prós:Solução mais simples (em termos de código e estrutura), boa flexibilidade (por exemplo, fácil de "ressuscitar") pedidos). Contras:As tabelas podem ficar muito grandes, um problema tanto para consultas quanto para, por exemplo, cópias de segurança.
• Arquive coisas antigas em uma mesa separada. Resolve os problemas desde a primeira abordagem, ao custo de maior complexidade.
• Use tabela com particionamento baseado em valor. Isso significa que logicamente (para o aplicativo) tudo está em uma tabela, mas nos bastidores o SGBD coloca as coisas em áreas separadas dependendo do(s) valor(es) em alguma(s) coluna(s). Você provavelmente usaria a coluna "completo" ou a "data de conclusão do pedido" para o particionamento.

A última abordagem meio que combina as partes boas das duas primeiras, mas precisa de suporte no SGBD e é mais complexa de configurar.

Observação:

As tabelas que armazenam apenas dados "arquivados" são comumente chamadas de "tabelas de arquivamento". Alguns DBMS até fornecem mecanismos de armazenamento especiais para essas tabelas (por exemplo, MySQL), que são otimizados para permitir recuperação rápida e boa eficiência de armazenamento, ao custo de alterações/inserções lentas.