3 ms·
some of this is a little unclear. in particular how the source invoices are identified and mapped and therefore what invoiceMap really looks like. but here is a
by convolvatron 5y ago
some of this is a little unclear. in particular how the source invoices are identified and mapped and therefore what invoiceMap really looks like. but here is a group/sum in a madeup datalog dialect:
reconcile(dstId, amount) :-
Orders(srcOrder)
Invoices(srcInvoice, srcOrder)
unique(dstId, srcInvoice.id)
amount = {
sourceInvoice.id = dstId,
sum (srcInvoice.Amount)
}
that produces invoice/sum pairs. Orders and Invoices are your source relations. unique produces a set of unique source invoice ids, which drives the cardinality of the aggregate. the block notation is a scoping construct encapsulate the set cardinality changes.
not going to claim that this is inherently more readable or captures all the subtleties. but you can imagine that terse expressions of intent like this are more accessible to the reader and less error prone. if not, I should do a better job.
- magicalhippo 5y agoSorry, I was in a bit of a hurry. An Invoice has essentially these fields: id InvoiceNo InvoiceDate Amount Currency The id is the unique id in the DB. For the purposes of consolidation we consider (InvoiceNo, Currency) as a tuple. For brevity I didn't include the failure mode of mismatching invoice dates, that can be checked in advance anyway so not terribly relevant. The invoiceMap maps instance to instance, or the unique id to unique id if you like.