4 ms·
I'm extremely out of my expertise here, but I'll see if I can spark some conversation. While possible with older SQL's through your own code, distributed shard
by spicybright 5y ago
I'm extremely out of my expertise here, but I'll see if I can spark some conversation.
While possible with older SQL's through your own code, distributed sharding and keeping multiple databases in sync I would think be useful at a DB level vs user code level.
You can certainly argue that shouldn't be part of the database software though.
- bob1029 5y agoI think it should be the job of the application logic to handle replication, validation and recovery of persisted business objects. Deferring this responsibility to some middleware is not something I am a big fan of. There are powerful arguments for using some off-the-shelf solution, but I also like being able to set breakpoints in the logic that ties all of the computers together.
- MrStonedOne 5y agoThere are things the db side would be better posed to handle and understand wrt replication. Moving it to application code requires a trade off and also everybody copying the same code in all of their applications for no reason other then somebody decided the application should be the one to handle it.
- anticristi 5y agoI can't argue against that iff the team has this capability. Unfortunately, I saw too many teams that end up implementing an informally-specified, bug-ridden, slow implementation of half of PostgreSQL.
- cornel_io 5y agoIf you've ever used Spanner you'll quickly decide that it absolutely makes sense for the DB to handle almost all of this stuff itself, it's a wonderful system that is sadly prohibitively expensive for many (most?) use cases outside of Google.