|
|
|
|
|
by PeterCorless
1638 days ago
|
|
1. If you need to share all the data and the data distribution methods across multiple legal entities — there's no one 'owner' of the data like a company. If you are doing a blockchain implementation for an internal project... why? Why are you not just using a regular database like Postgres or MongoDB or Oracle or ScyllaDB? But if you are going to be sharing all this data across 50-100 companies, and no one themselves wants to "own" the project and host it, and if everyone wants to be participating as a near equal partner in a solution? Okay. Maybe distributed ledger is warranted. 2. If you need to be able to add more entities who want to participate in the distributed ledger. Or, conversely, drop out entities that are no longer participating, but everyone else still wants to preserve the history of their transactions. If you do deploy to a centrally-owned databsase, if the managing entity ever wants, for any reason, they can pull the plug on the whole operation. A distributed ledger ensures you can add people at any time — no one can lock you out from joining. And also it ensures that if you ever want to leave, the data and the work continue. 3. If you need strongly-consistent views of data, and you don't care about transactional limits. Most distributed ledger technologies are greatly bottlenecked in terms of transactions per second. And I mean some are limited to less than 10 transactions per second. Others can scale to thousands of operations per second. But many centrally-managed and even distributed databases can operate at millions of operations per second. So blockchain is not going to do anything like "eventual consistency." It just won't. And because of that, you'll have these strong throughput (ops per second) limits. |
|
This basically means most of the examples in IBMs marketing (supply chain management, vaccine rollouts etc) don’t actually make any sense to do on blockchain vs using a regular database.