200 ms·
You'd use a private, permissioned blockchain over federated SQL databases due to the technical difficulties of synchronizing audit tables across organizational
by freeone3000 5y ago
You'd use a private, permissioned blockchain over federated SQL databases due to the technical difficulties of synchronizing audit tables across organizational boundaries -- since an enterprise blockchain is append-only, immutable, time-stamped, and each new entry has a hash of the previous view, it overcomes a lot of data integrity issues inherent to a distributed SQL database. None of the companies here will fully trust each other to hold an exclusive copy of the data, so the blockchain here replaces an expensive manual reconciliation step in the event local accounting databases don't match up.
As an external user? Nobody cares, it's not for you, move on.
- CRConrad 5y ago> since an enterprise blockchain is append-only, immutable, time-stamped, and each new entry has a hash of the previous view, it overcomes a lot of data integrity issues inherent to a distributed SQL database. And why couldn't a distributed SQL database be append-only, immutable, time-stamped, and implemented so each new entry has a hash of the previous state? (If you own it, just set it up to disallow updates or deletes, and allow inserts only through a trigger / stored procedure that adds the timestamp and hash.)
- freeone3000 5y agoIt could, and then it'd be a blockchain in SQL, like MSSQL's BLOCKCHAIN table type. Those features are definitional to a blockchain.