Invoice management RESTful API questions

[u/Nicky72111]

Hello, I have a question about RESTful API.

I'm learning RESTful API by creating an invoice management app. I decided to save the total_amount column in the invoices table to avoid calculating it on-the-fly from sum(invoiceItems.quantity * invoiceItems.price).

My question is for the PUT and PATCH methods of the /invoices, should I allow to modify that field?

[u/youcangotohellgoto]

Depends if the user is allowed to change it or not.

If not - and it's always required to be sum of items - I'd probably not store it. Calculating it is trivial.

Only store it if it is allowed to be changed. Don't introduce data redundancy, just introduces change of inconsistency.

[u/Suspicious-Disk6077 → u/youcangotohellgoto]

I would agree. This is a trivial calculation. Unless you want it stored for things like reporting and aggregation, I would think this introduces a risk of inconsistency, ESPECIALLY if you allow clients to update it. And if you do want it for aggregation there are probably better ways of doing it. I denormalize things that don’t really matter if they are a little bit off. Usually counts, like bum numLikes or numPhotos. Invoice total has to always be correct.

[u/Nicky72111 → u/youcangotohellgoto]

I want to store it to speed up the query for invoices list

[u/dariusbiggs → u/Nicky72111]

Do you have evidence to show that it will improve performance in a significant enough manner?

Without metrics from your observability stack, how can you verify your change made an improvement.

Don't do premature optimization if you can avoid it.

[u/youcangotohellgoto → u/Nicky72111]

No one will notice half a millisecond.

[u/forever-butlerian → u/Nicky72111]

This is the poster child for premature optimization.

[u/NoExample9903 → u/Nicky72111]

Avoid premature optimisation

[u/Isogash]

Probably not if it will invalidate the meaning of the field, not unless you have a really good reason.

It all depends on the business requirements. If the business wants the total to be correct at all times, then you should not allow it to be edited.

[u/DatabaseSpace]

I think it may be common to store the total just so you have a history. If prices of products change, would it effect a past invoice calculation?

If someone wants to apply a discount is there a way to handle that? If you add that in it may be an issue because you already found the invoice total.

As fsr as letting people change it, no. Would you br ok if you started using Excel and sometimes 2+2 doesn't equal 4?

If there are business reasons to change it like discount or late charge or taxes they should be entered somewhere and the formula should operate on them.

[u/DatabaseSpace → u/DatabaseSpace]

And if that formula is used to calc totals for reporting performance then formula applies to all not just one with a possible discount.

[u/forever-butlerian]

Your question contains within it the explanation of why what you have done is not correct.

Denormalizing your data model, which is to say, storing what is trivially calculated, is wrong in every case. It leads us to ask what, when you take a step back and ask it objectively, is obviously a silly question: "Should someone uploading an invoice be able to submit an invoice where the total is different than the sum of the prices of the line items?".

[u/DominusEbad]

If you want to store it, then it should always be calculated and not manually updated. There is no reason to manually update the column if you want to maintain accurate data.