Silberengel @Silberengel - 7d
Ever tried migrating one? They're often absolutely gigantic, full of procedures and complex views and classes (tables), and function as de facto interfaces for myriad other applications. And you usually have to migrate in production, or run it in parallel with the new one, for months. And for little gain, other than decreasing your maintenance work by increasing the chances of joining the AWS 7-hour outage.
Also, look at the type of applications still running Oracle. It's like with COBOL: all the stuff that CANNOT GO DOWN, DON'T MOVE IT EVER, EVERYONE'S LITERALLY GONNA DIE. Fun fact: COBOL was my second programming language and Oracle was my first DB. We regularly get requests for maintaining both of those things, and it pays well. 😊
David @mleku - 7d
this is the plague of centralized databases and something that the nostr architecture can fix. most of the solution relates to distributed replication and multi-server fetching strategies, though the tech being used for this is still pretty primitive on most relays.
They often capture and distribute the events during the input/output step, to have multiple instances of the same data set, at different company offices. Their events have unique keys, now. It's all moving toward the Nostr concept, it's true.
yup... all that's needed is some more experimentation with distributed dynamic cache strategies and more use of the pub/sub model... the sub side is there already, and can be relatively simply made to run, but push side needs to be there too, or at least, a model of subscription in which the emitted events are in a queue and when a subscriber drops, they get sent the backlog they miss in the interim. this isn't really that complicated to implement either, in fact, i wrote a sub thing using SSE but all i have to do to make it resilient is create a primary subscription queue and progress monitoring of subscribers and a slightly different contract than the best effort that is the current standard.
