Início / user-1613

humble_coder's questions

Martin Hope
humble_coder
Asked: 2014-11-15 09:30:22 +0800 CST
  • 1

Tenho uma tabela com cerca de 6.000.000 de registros. É feito backup a cada poucas horas. Recentemente, um script executado em cascata atualizou cerca de 2.000.000 dos registros mais antigos para valores inválidos. Eu extraí esses 2.000.000 registros do backup e os tenho prontos para reinserir, na forma de "INSERT INTO table (col, col) values ​​(val, val)"

Agora, preciso de um mecanismo para inserir esses 2.000.000 registros, substituindo os dados inválidos pelos dados históricos, mantendo os IDs existentes (o que significa que REPLACE não é uma opção - pois exclui em duplicata e incrementa o ID). Além disso, preciso fazer isso sem interromper o acesso ao servidor por muito tempo (o que significa DROP TABLE, então --force trickery não é uma opção).

Tenho certeza de que estou perdendo alguma coisa, mas não consigo descobrir como substituir no local dentro dos parâmetros atuais. Pensamentos?

mysql insert
Martin Hope
humble_coder
Asked: 2011-06-22 11:41:42 +0800 CST
  • 2

Ainda estou trabalhando no projeto mencionado aqui (http://dba.stackexchange.com/questions/2428/how-do-i-properly-design-a-many-to-many-charges-payments-accounting-system ).

O sistema deve dar ao usuário a opção de pagar quantias específicas em cobranças específicas ou fazer pagamentos genéricos "você descobre". Dada a estrutura da tabela que usamos (PAYMENTS, CHARGES, PAYMENTS_TO_CHARGES), estou tentando trapacear um pouco. Basicamente, estou procurando uma consulta SQL "reconciliar" incrivelmente elegante que fará o seguinte:

PASSO 1) Pegue todos os pagamentos com saldo restante (basicamente créditos)

PASSO 2) Pegue todas as cobranças com saldo restante (parcialmente pago, etc)

PASSO 3) Insira parcelas de pagamentos na tabela PAYMENTS_TO_CHARGES até que não haja mais crédito disponível ou não haja mais cobranças.

…Eu acho que tecnicamente isso não é tanto uma reconciliação quanto a criação de dados transacionais, mas você entendeu.

Os passos 1 e 2 são obviamente muito fáceis. É a Etapa 3 que é o assassino. Se não houver uma maneira elegante de fazer isso em SQL, suponho que irei com o antigo passo a passo codificado à mão para cada transação e postar payment_to_charge... apenas pensei em perguntar.

Desde já, obrigado!

EDIT 1: Eu criei esta consulta para determinar quais cobranças têm saldo restante, mas está me dando um erro dizendo "Coluna desconhecida 'remaining_balance' in 'where clausule'":

SELECT 
       charges.*
     , (charges.amount - transactions.total_paid) as remaining_balance 
FROM charges
   , (SELECT 
             charge_id
           , sum(amount) as total_paid 
      FROM payments_to_charges 
      GROUP BY charge_id) as transactions 
WHERE charges.member_id = 123 
  AND charges.id = transactions.charge_id 
  AND remaining_balance > 0 
  AND charges.active_on < NOW()

Tenho certeza de que alguns itens estão simplesmente fora de ordem, mas não consigo descobrir o que geralmente há de errado com essa consulta específica. Devo usar HAVING em vez de WHERE? Estou perdendo algo completamente óbvio?

transaction query
Martin Hope
humble_coder
Asked: 2011-04-29 08:59:20 +0800 CST
  • 2

Esta é tanto uma questão de db/programação quanto uma questão de contabilidade/matemática, então estou postando em todos os fóruns relevantes. Eu aprecio sua paciência com antecedência.

Basicamente, estou tendo problemas para entender um livro de pagamentos. Meu sistema tem três tabelas: CHARGES, PAYMENTS e PAYMENTS_TO_CHARGES. O problema é que parte do requisito do sistema exige a capacidade de associar diretamente um pagamento a uma COBRANÇA, bem como permitir que os membros postem pagamentos em excesso (ou créditos) em suas contas. Portanto, há a necessidade de rastrear os créditos e aplicá-los conforme necessário para ENCARGOS futuros.

Talvez eu esteja pensando nas coisas do ponto de vista errado, mas estou imaginando ENCARGOS como DÉBITO e PAGAMENTOS como CRÉDITO. No entanto, parece que ambos podem ter DÉBITO/CRÉDITO, dependendo da sua abordagem contábil.

Portanto, minha pergunta - oficialmente - é qual é a melhor maneira de rastrear / reconciliar pagamentos e cobranças, enquanto ainda permite pagamentos em excesso etc. Estou tentando descobrir as tabelas de banco de dados e a lógica de negócios, mas sempre Eu resolvo um problema, um item reverso (ou inverso) se apresenta. Permito que o relacionamento muitos-para-muitos rastreie números positivos e negativos por transação? Eu crio uma cobrança universal falsa à qual todos os créditos se aplicam? Devo criar uma tabela CREDITS completamente separada? Como você pode ver, provavelmente estou pensando demais nisso, mas certamente estou confuso.

Se todas as transações fossem garantidas de 1 para 1, obviamente seria muito mais simples. Infelizmente eles não são

Veja também:

https://softwareengineering.stackexchange.com/questions/72178/how-do-i-properly-design-a-many-to-many-charges-payments-accounting-system

e

https://stackoverflow.com/questions/5543025/need-to-reconcile-accounts-on-a-poorly-designed-system

database-design