Big battles and the difficulty of translating a database to a new engine are two totally different problems.
The big battles lag are a combination of the speed of the server having to calculate the position of tens of thousands of moving parts while receiving and responding to input chains from across the globe all moving at different speeds across the crazy quilt of the internet. The solution in the industry is shards or player caps which goes against the basic principle of Eve being a single shard. As most third party engines you can purchase with a big credit card employ the shard limit schema, they’re not the best idea for Eve. Even these third-party solutions lag if your connection isn’t fast enough or interrupted.
Database is its own beastie. Forget Eve is a game for a moment. Imagine Eve as the database for a huge mega-corporation with hundreds of thousands of employees, of which at any time about 30-40 thousand are making transactions in real time against the company inventories and ledgers.
These databases are usually tied to programs that make them usable to the employees, either an in-house solution or a package that is bought from a large vendor, that makes reports for the executives and employees to use to make business decisions. That’s your Eve Client and any API’s for the folks watching at home.
Do the engines and their reports need updated from time to time? Absolutely. Many business modules are programmed in COBOL or old version of Crystal reports, or some other incredibly archaic interface that looks like Windows 3.1 and need converted to something new so they can be used with the cloud. Bank regulations change, so the credit card module needs updated so it’s security compliant. This stuff happens on a regular basis. In eve you get UI changes, new ships, new items, whole bunch of things that are simply a client report pulled from the database, just in shiny object form.
Most of the time the customer will patch the existing software as the existing software is already optimized for that company’s data and this is the less expensive and less disruptive solution. Outages and data problems still happen, especially if a patch is rushed, but at a manageable rate that can normally be resolved from backup or a rollback. Eve is that company opting to patch modules as they go, as what they have at present fits their data like a glove. Sometimes they’ll make a new component that plugs in to the old data and sometimes they’ll adjust the tables so that it works better but this is a very much trial and error process involving time and repeated attempts to get right.
CCP gets a nod of respect from me for how long they’ve kept it running with the complexity involved even if it’s not perfect. They’ve sure done a better job than the consultants at my workplace keeping the database running consistently.
Now, sometimes it’s absolutely necessary to bite the bullet and switch to either a new database engine, or a full revision of the current database engine. Program is no longer supported or the programmer died of old age (this does happen), can’t get Windows 98 computers any more, any number of reasons. This is a costly process involving months of testing and debugging and if everything is not done and tested precisely will cause a huge amount of problems and incorrect data going forward. You wouldn’t want to lose your titan to a rounding error, would you?
Lots of companies cut corners and don’t do the proper testing time as the consultants who usually do this work get paid enough to drive Ferarris and Teslas and have two or three in the garage. When you’re dealing with in-house guys only to save costs you run in to the very human risk of “this is how we’ve always done it,” syndrome which is hard to break out of if the old way has usually worked.
Good luck if you’re going to a different engine type entirely for your data. I’ve had the “pleasure” of saving old tables and data schemas from outdated systems and trying to make them usable for something else. I marginally succeeded. No, I was not paid in ferarris.
The tables are usually a mess, make no logical sense as the programmer notes are not available or no longer there, or simply won’t work with a new engine as part of the table was deprecated five updates ago. There is a staggering amount of forensics work involved in trying to take a massive database and figuring out how it all works together then translating it to work in a new system, even under ideal conditions.
AI and Neural Nets are not usable for this as in order to get the desired output you have to program set “values” in to the neural net and if you are not explicit with those values (such as, use proper grammar), the machine will get real “creative” with the results. View them more as incorrigible toddlers who will gladly wash the dog in pink dye as it was not told to them specifically that this is not allowed when you gave the command to “wash the dog.”
From CCP’s perspective, why risk destroying a mostly working product when you’ll have more consistent results and fewer major failures by massaging a system here and there and working with that smaller set of results? The structures transition from POS to ship-like things are a good example. New UI modules are made with new tables to work with new technology and while not perfect they are an advancement.
It doesn’t cost a programmer much to write a fiscal report off the existing tables with some creative math inside the report, certainly not as much as rebuilding a database from scratch chasing the optimization unicorn that transforms about once every six months in to a new beast. You’ll never catch that beast and you’ll die trying.