Modelando restrições em agregados de subconjuntos?

Estou usando o PostgreSQL, mas acho que a maioria dos bancos de dados de ponta precisa ter recursos semelhantes e, além disso, que as soluções para eles podem inspirar soluções para mim, então não considere isso específico para o PostgreSQL.

Sei que não sou o primeiro a tentar resolver esse problema, então acho que vale a pena perguntar aqui, mas estou tentando avaliar os custos de modelagem de dados contábeis, de modo que todas as transações sejam fundamentalmente equilibradas. Os dados contábeis são apenas anexados. A restrição geral (escrita em pseudo-código) aqui pode parecer aproximadamente:

CREATE TABLE journal_entry (
    id bigserial not null unique, --artificial candidate key
    journal_type_id int references  journal_type(id),
    reference text, -- source document identifier, unique per journal
    date_posted date not null,
    PRIMARY KEY (journal_type_id, reference)
);

CREATE TABLE journal_line (
    entry_id bigint references journal_entry(id),
    account_id int not null references account(id),
    amount numeric not null,
    line_id bigserial not null unique,
    CHECK ((sum(amount) over (partition by entry_id) = 0) -- this won't work
);

Obviamente, essa restrição de verificação nunca funcionará. Ele opera por linha e pode verificar o banco de dados inteiro. Por isso, sempre falha e demora a fazê-lo.

Então, minha pergunta é qual é a melhor maneira de modelar essa restrição? Até agora, olhei basicamente duas idéias. Pensando se esses são os únicos ou se alguém tem uma maneira melhor (exceto deixá-lo no nível do aplicativo ou em um processo armazenado).

1. Eu poderia pegar emprestada uma página do conceito do mundo contábil da diferença entre um livro de entrada original e um livro de entrada final (diário geral versus contabilidade). Nesse aspecto, eu poderia modelar isso como uma matriz de linhas de diário anexadas à entrada do diário, impor a restrição na matriz (em termos do PostgreSQL, selecione sum (amount) = 0 da unnest (je.line_items). salve-os em uma tabela de itens de linha, na qual restrições de colunas individuais poderiam ser aplicadas com mais facilidade e onde índices etc. poderiam ser mais úteis.
2. Eu poderia tentar codificar um gatilho de restrição que aplicaria isso por transação, com a ideia de que a soma de uma série de 0s sempre será 0.

Eu os estou comparando com a abordagem atual de impor a lógica em um procedimento armazenado. O custo da complexidade está sendo pesado contra a ideia de que a prova matemática de restrições é superior aos testes de unidade. A principal desvantagem do nº 1 acima é que tipos como tuplas são uma daquelas áreas do PostgreSQL em que se depara com comportamentos inconsistentes e mudanças nas suposições regularmente e, portanto, eu espero que o comportamento nessa área possa mudar com o tempo. Projetar uma versão futura segura não é tão fácil.

Existem outras maneiras de resolver esse problema que escalarão até milhões de registros em cada tabela? Estou esquecendo de algo? Existe uma troca que eu perdi?

Em resposta ao ponto de Craig abaixo sobre as versões, no mínimo, isso terá que ser executado no PostgreSQL 9.2 e superior (talvez 9.1 e superior, mas provavelmente podemos seguir com o 9.2).

Como temos que abranger várias linhas, ela não pode ser implementada com uma CHECKrestrição simples .

Também podemos descartar restrições de exclusão . Essas abrangem várias linhas, mas apenas verificam se há desigualdade. Operações complexas como uma soma em várias linhas não são possíveis.

A ferramenta que parece mais adequada ao seu caso é uma CONSTRAINT TRIGGER(ou apenas uma simples) TRIGGER- a única diferença na implementação atual é que você pode ajustar o tempo do gatilho SET CONSTRAINTS.

Então essa é a sua opção 2 .

Uma vez que podemos confiar na restrição que está sendo aplicada o tempo todo, não precisamos mais verificar a tabela inteira. Verificar apenas as linhas inseridas na transação atual - no final da transação - é suficiente. O desempenho deve estar bem.

Tambem como

Os dados contábeis são apenas anexados.

... precisamos nos preocupar apenas com as linhas recém- inseridas . (Supondo UPDATEou DELETEnão possível).

Uso a coluna do sistema xide a comparo com a função txid_current()- que retorna a xidtransação atual. Para comparar os tipos, a conversão é necessária ... Isso deve ser razoavelmente seguro. Considere isso relacionado, depois responda com um método mais seguro:

• Como visualizar tuplas alteradas em uma transação do PostgreSQL?

Demo

CREATE TABLE journal_line(amount int); -- simplistic table for demo

CREATE OR REPLACE FUNCTION trg_insaft_check_balance()
    RETURNS trigger AS
$func$
BEGIN
   IF sum(amount) <> 0
      FROM journal_line 
      WHERE xmin::text::bigint = txid_current()  -- consider link above
         THEN
      RAISE EXCEPTION 'Entries not balanced!';
   END IF;

   RETURN NULL;  -- RETURN value of AFTER trigger is ignored anyway
END;
$func$ LANGUAGE plpgsql;

CREATE CONSTRAINT TRIGGER insaft_check_balance
    AFTER INSERT ON journal_line
    DEFERRABLE INITIALLY DEFERRED
    FOR EACH ROW
    EXECUTE PROCEDURE trg_insaft_check_balance();

Diferido , portanto só é verificado no final da transação.

Testes

INSERT INTO journal_line(amount) VALUES (1), (-1);

Trabalho.

INSERT INTO journal_line(amount) VALUES (1);

Falha:

ERRO: Entradas não equilibradas!

BEGIN;
INSERT INTO journal_line(amount) VALUES (7), (-5);
-- do other stuff
SELECT * FROM journal_line;
INSERT INTO journal_line(amount) VALUES (-2);
-- INSERT INTO journal_line(amount) VALUES (-1); -- make it fail
COMMIT;

Trabalho. :)

Se você precisar impor sua restrição antes do final da transação, poderá fazê-lo em qualquer ponto da transação, mesmo no início:

SET CONSTRAINTS insaft_check_balance IMMEDIATE;

Mais rápido com gatilho simples

Se você opera com várias linhas INSERT, é mais eficaz acionar por instrução - o que não é possível com acionadores de restrição :

Os gatilhos de restrição podem ser especificados apenas FOR EACH ROW.

Use um gatilho comum e atire FOR EACH STATEMENTpara ...

• perder a opção de SET CONSTRAINTS.
• ganhar desempenho.

EXCLUIR possível

Em resposta ao seu comentário: Se DELETEpossível, você pode adicionar um gatilho semelhante, fazendo uma verificação do saldo de toda a tabela após a ocorrência de um DELETE. Isso seria muito mais caro, mas não importará muito, pois raramente acontece.

A solução a seguir do SQL Server usa apenas restrições. Estou usando abordagens semelhantes em vários locais do meu sistema.

CREATE TABLE dbo.Lines
  (
    EntryID INT NOT NULL ,
    LineNumber SMALLINT NOT NULL ,
    CONSTRAINT PK_Lines PRIMARY KEY ( EntryID, LineNumber ) ,
    PreviousLineNumber SMALLINT NOT NULL ,
    CONSTRAINT UNQ_Lines UNIQUE ( EntryID, PreviousLineNumber ) ,
    CONSTRAINT CHK_Lines_PreviousLineNumber_Valid CHECK ( ( LineNumber > 0
            AND PreviousLineNumber = LineNumber - 1
          )
          OR ( LineNumber = 0 ) ) ,
    Amount INT NOT NULL ,
    RunningTotal INT NOT NULL ,
    CONSTRAINT UNQ_Lines_FkTarget UNIQUE ( EntryID, LineNumber, RunningTotal ) ,
    PreviousRunningTotal INT NOT NULL ,
    CONSTRAINT CHK_Lines_PreviousRunningTotal_Valid CHECK 
        ( PreviousRunningTotal + Amount = RunningTotal ) ,
    CONSTRAINT CHK_Lines_TotalAmount_Zero CHECK ( 
            ( LineNumber = 0
                AND PreviousRunningTotal = 0
              )
              OR ( LineNumber > 0 ) ),
    CONSTRAINT FK_Lines_PreviousLine 
        FOREIGN KEY ( EntryID, PreviousLineNumber, PreviousRunningTotal )
        REFERENCES dbo.Lines ( EntryID, LineNumber, RunningTotal )
  ) ;
GO

-- valid subset inserts
INSERT INTO dbo.Lines(EntryID ,
        LineNumber ,
        PreviousLineNumber ,
        Amount ,
        RunningTotal ,
        PreviousRunningTotal )
VALUES(1, 0, 2, 10, 10, 0),
(1, 1, 0, -5, 5, 10),
(1, 2, 1, -5, 0, 5);

-- invalid subset fails
INSERT INTO dbo.Lines(EntryID ,
        LineNumber ,
        PreviousLineNumber ,
        Amount ,
        RunningTotal ,
        PreviousRunningTotal )
VALUES(2, 0, 1, 10, 10, 5),
(2, 1, 0, -5, 5, 10) ;