Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I love postgresql.

Did business with a startup, signed up, started getting service, they play an intermediary biller / payor role.

Because of an issue in company name used in signup their billing system fell over and didn't setup billing.

But what was crazy is a quickly realized this shop was a noSQL shop. NOTHING connected to anything - so since they hadn't built any reports to cross check any of this they literally did not notice (I noticed other consistency issues elsewhere).

In a SQL database this stuff especially around accounting / money is 101 stuff, but noSQL seemed to really struggle here based on how they'd set it up.

I finally bugged them to charge us, but even that was a bit goofy (basically it looked they exported some transaction to a credit card system - but I doubt had any logic to handle failed payment issues etc).

We have one other vendor where the amount actually charged is a few pennies off the receipt totals - issues with doubles, rounding and application logic or something which doesn't simply use the same number (from database) for order / item detail and total and billing.

So at least in finance / accounting, a ledger which is basically a source of truth, and is linked / summarized / etc in various ways to other parts of systems (sales tax, receipts, credit card charges by order etc) really results in some free consistency wins that don't seem to free in nosql land.



Operational data stores are not reporting data stores. A healthy system would fire change events to which a reporting system subscribes, placing the data where it belongs in the reporting data model.


Except what happens when change events are dropped.

in SQL, normalized, ref integrity on - you simply never get out of sync.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: