I would recommend building a 20000ft^2 subterranean anti-methhead-bunker 100ft under ground. This will also allow you to survive Trump.
Install a lift up into a hidden room inside a non-descript looking shed. Obviously the lift will only work via DNA verification anyway.
You should fill the bunker with snakes, scorpions and taratulas, apart from your work area (6x6 ft), this will dissuade people who have cloned you to get into the lift.
As for the work area, I recommend a bulletproof chair that enconses your body as you work.
Cost of production in the pharmaceutical industry has no correlation with the sale price.
This will be sold initially for billions per treatment. Then hundreds of millions. Then tens of millions.
Beneath this, it absolutely will have to make up for the loss of income from other age-related medications and treatments that this would kill, especially if it was available to all. Otherwise it would be an effective way for social governments to deal with the high medical cost of retirement aged people - eradicate the getting old part.
As I wrote elsewhere - immortals will spend their days evading capture by hunter-killer terminator robots.
Nah, best bet is that at 150 you go into clinic for your next rejuvenation treatment unaware of the following intents: you're tranquilised, and then fed into 'the machine' (industrial grinder / furnace). Even better, make it religious, so they queue up for the machine. Sadly some upstart will likely find out and ruin it for everyone else.
I just know that I'll have 40000 project that I've put off for another day that I suddenly feel motivated to finish around that time. Typical.
If rejuvenation means fertility too (thank gawd there are a limited number of eggs in a woman), then birth rate per person may increase over time.
Sure, 1 or 2 children is the western standard these days, but that's because of the small window of opportunity.
There are going to be people, whose children left the nest, who get rejuvenated and who want a new child. If you live to 200, you might have children at 30-40, 60-70, 100-110, 150-160 (a 40 year gap!). OTOH maybe due to housing shortages having your 80 year old child hanging around home might put people off.
If you live to 1000? Even if you settle on a child a century, that's a lot of children.
I'm guessing that floating cities, hyper-stilted cities (shallow seas), transformed deserts, etc, would all occur anyway in the next 50-100 years.
Given a sudden lack of death in the world population (it would take a while in truth) that might buy a few decades on Earth.
It'd be a lot cheaper to allow colonists to take only digital property, personal tech, and some clothes - everything else they can get at their destination. Some of these things could be made in space rather than be lifted too.
Send the people who have lived a life, have extended it, and the price for extending it is being space colonists - Mars, Ceres, Titan, etc. Retire on Earth in a bungalow eating Soy-Lent watching NetFlix, or go into space rejuvenated by 20 years? They can build out space, and when disasters happen, at least the victims had already lived and understood the risk.
Sadly that leaves the rich people on Earth with their life extensions, just sucking up more and more money like the worthless financial black holes they are. They'll still be eating beef and ruling, and trying to stop progressive options like the above.
Most people currently live in a post-inheritance world - either they get funding from living parents, or unless the parents are particularly rich, retirement, health care, care homes, etc, grabs so much of what was built up in savings during life that anything that dribbles down to the children (who are already in their 40s to 60s by this stage) doesn't really pay for a lot so much so that many inheritances jump a generation now.
So IMO if you are relying on an inheritance to get on in life in the future, then you may be disappointed.
Note too that end-of-life treatment is the majority of the healthcare cost over a lifetime for most people. If this treatment can eventually be fairly cheap, then it may be better to always apply it to people rather than let them get close to dying and being costly. In that way, you will be hoping that rapid-death scenarios happen to keep some form of turnover in population - accidents, etc. Maybe older people bored with life will be encouraged to take riskier and riskier holidays...
You can't deny that moving excess people to various floating deadly rocks doesn't solve the overpopulation problem on Earth. The technology will evolve to get to these places over time, although getting it to affordable rates may take a lot longer.
It is likely that the birth rate would continue to drop as well, and with life expectancy extensions - in particular if women could stay fertile for longer (maybe difficult with the limited set of eggs they are born with, but I'm sure they can be kept around too) - it will likely extend even more, as people continue to stay children to older ages (both definitions of 'stay' apply here).
People would still die too, but that would move from ~70-80 years old to ~100-~120 years old on average initially. The concern is that the prolonging therapy evolves over time to be repeatable, and more effective, meaning people will live to a very very long time, and people may already be alive who will benefit from this.
I think there are strong arguments to society being stronger with new blood (to eradicate rich Trumps). So maybe forced exile to the stars once you hit a certain age is an idea. You've had a life, now continue it elsewhere building a new society from scratch, with all that experience you should have gained. And if it all goes tits up, hey, you did live a long time already, don't whine about it (not that your whines will be heard back in our solar system).
Funding mechanisms for the massive cost to society of people hanging around longer will need to be found. Fit for work doesn't mean much work will exist in the future due to automation...
That's if we're not all scrabbling for scraps in a post-Trump nuclear winter.
How about you reply to the points raised instead of avoiding them?
The situation is that the level of Methane in the atmosphere (net of new methane production/emission and methane breakdown) is going up significantly, and there's a lot more waiting to be emitted.
What do they say in the paper about when the 'modern period' is. For example, is it post-industrial average? Average between 1950-2000? Average between 1000 and 2000?
Additionally it's only the summer warning we care about when we consider maximum absolute temperature - so that's 2-6C - and it was highly localised. Global temperature averages during the HCO were still below today's temperatures (but maybe still above the 'modern period' temperatures).
Regardless, that doesn't mean that during the warm period the bogs in Siberia weren't emitting a lot of methane during the summers and trapping it during the winters, so that a lot of the currently trapped methane is actually more recently sourced. Maybe someone's done some research here. I'd theorise that one reason Siberia was so much warmer during the HCO compared to globally was that there was a local source of warming gases being emitted contributing to the warming.
Well yeah, it's hard to argue against that level of incompetence (that's exactly the case of being hired for a skill and then not having that skill). Luckily there's code review and on-the-side feedback to the manager, etc.
Sheesh creimer, you should have parallelised that script in your free time and run it on the non-existent compute cluster... blah blah blah.
It's the jobs without slack time where the mistakes get made (at all levels). Let the employee kick back occasionally, surf the web (hell, reading technical websites is hardly the worst thing you can do in a technical role), do things safely.
And hell, if your manager has told you to only do one task/story at a time, then who am I to say you shouldn't!
Only do the things in (3) that will help you get a new job.
The EIP will not be "Just do X, Y, Z", it'll be a weekly-reviewed self-documented long list of things to be attaining. If the company is reasonable, it will be doable. If they want you out, it won't be - so just concentrate on the things that you like the sound of the most, and avoid the soft-skills crap that is hard to quantify.
If the cause of lower performance is transitory (say, a year long divorce/house move/depression type thing, and the employer is still being harsh on you) then it can be useful to switch job anyway - new jobs are more interesting, learning opportunity, no historical weight, often little legacy crap to deal with - just concentrate on getting through the probation period and hopefully things will ease up in your life (and the stress-break from changing job and losing the EIP will help massively) and then you can move on and forget the bad year or two.
The biggest issue for an employee is under-motivation and/or procrastination (as in, serious internet addiction level) that is not transitory. In that case, well, yeah - visit all your sites in the evening, leaving the morning at-work surf fairly minimal. Hope the work place blocks sites. Etc.
Or you'll get a team that rotates the lowest performing member, as it might require two reviews in a row to hit EIP.
Shame if that means you get no bonus this year, at least the next four you'll get one. Oh, the company did great this year and the bonus is 3x bigger than normal... oh, you've left?
Yes, small teams that work together, who own their own projects, where the projects don't get large (create new projects for new functions) and who aren't held back by external forces as long as they generally follow some basic rules (language, db, api structure, documentation, builds, and so on) generally can get things done.
Super-large old monolithic architectures that have been appended to over many years and now have a team of 30+ basically maintaining it and desperately splitting the tangled code into seperate services talking via RMI to keep development time down, until they hit serialisation versioning hell, and then morale drops and everyone wonders why the front-end ajax interface is rendered in the server side via some weird codified templating system that results in tears instead of hiring people who know Javascript for the front end and trying to do things simply, cleanly and concisely... well yeah, that can get skilled people down.
The first case - you have a team owning N microservices. Team gets too big - the split is easy (well, easier than the second case of having separate teams own parts of the same monolithic codebase), two smaller teams, each with N/2 microservices. Best keep some FE and MW on the same teams though, don't go the route of FE team and MW team, that way leads to more intra-team communications.
Using your example... that depends on whether the programmer is in a role that should be talking directly to the database, has self-identified (e.g., at interview) as knowing SQL and programming language interfaces to it, or has received training in-house to that level via whatever means.
Maybe the symptom isn't a bad programmer, but an in-house process that doesn't work - in this case maybe the company has an in-house DBA team that does DB programming work (and teams that create microservices that interface with the DB), but they are overloaded or don't respond to work tickets. The programmer has just tried a workaround to get something going rather than being blocked by the process for 4 weeks.
(yes, I know that any reasonably experienced programmer should know SQL to some level, but these days it's very easy to go years and years without touching it directly)
Yup, improvement programmes usually exist to document the failure of the employee to meet the demands of the programme, which are set to levels that can't be achieved day-in, day-out over the programme period. Obviously if there is an external issue creating the employee's problems, the programme simply adds stress to the situation they are in rather than even being anything like being a helpful assistance through a temporary situation.
It's usually only when that employee eventually leaves and finds another job that they realise the expectations of productivity from the previous role/programme were not attainable.
1. The supermarket's name is the full name of the country Iceland, and that's that. It's a source of mild amusement in the country to deliberately confuse the two, especially with the company's adverts which use "Mum's gone to Iceland" (because Dad didn't give her enough money to go to Waitrose, I presume, and other misogynistic themes). 2. But in English, not Icelandic. 3. And also the supermarket started off (and still mostly is) a specialist in low-priced frozen foods - hence the name - it wasn't named after the country. 4. The supermarket is enforcing its trademark to stop companies from Iceland use 'Iceland' in their name. 5. The country believes that this is unfair. 6. Maybe the country should consider some more exciting branding around volcanoes and rifts for their companies. 'Horsemeat Iceland' is all very well, but "Erupting Mid-Atlantic Ridge Horsemeateries" sounds better.
But those three calls in an SQL DB might map to the same single document in a NoSQL DB! Indeed that's one of the reasons for transactions in an SQL database - the tabular structure with fixed columnar schemas pretty much requires transactions for safety.
Maybe you only care about eventual consistency too?
What sort of transactional consistency do you require?
Do you care if it takes a short period to replicate across the cluster before it can be read again? NoSQL solutions include options, if you need that (e.g., i don't care, i want a quorum agreement on the read, all must agree (read from master, enforce writes through master), etc). Indeed these options are often what distinguish one NoSQL solution from another.
Are you only modifying a single document? Then you can do that atomically. Remember that document may represent a lot of tables in a RDBMS.
And maybe this use case is simply not suitable for a document database. RDBMS is great at these things - it just isn't great at some things NoSQL is great at.
Why are hundreds of people working on the same objects directly? That's screaming for a microservice interface on top for the 95% who are doing the same operations. And then suddenly the underlying system doesn't matter.
Most NoSQL solutions have a structure to the documents (because in the end they're serialised forms of Java/C#/etc objects), it's just that it isn't columnar. There can be arrays, inlined sub-objects, etc. And you can set indexes on these deeper aspects, and so on. The DB is optimised for tweaking at the object level of course, and locks at the object level (but doesn't provide multi-object transactions out of principle).
Some NoSQL solutions add some very cunning features to how you can define the structure of the data, you can do some funky things with Cassandra's slices, for examples (although it's been some time).
Exactly. If your company can afford a DBA team, then Oracle is an option. This will likely keep the money rolling in to Oracle for the foreseeable future.
If your company can't afford a DBA team, then you really need to look elsewhere, where-ever that may be (IMO PostgreSQL and Cassandra, maybe MongoDB, maybe ElasticSearch stack) and do a short period of trialing / proof-of-concepting to see what works best. However in this case one suggested recommendation is that you choose ONE company-wide SQL solution and ONE company-wide NoSQL solution, and only allow exotics on a case-by-case basis when the need is demonstrated.
TBH MongoDB 3.4 has graph queries. So assuming Solar Systems are linked by 'trade routes' or 'warp jumps' or even just linked to all systems within X light years, you should be able to use that effectively for route planning, getting all near systems, and so on, without a complex 3D geo-spatial lookup.
But it is application specific, without knowing the requirements, who knows what the use cases are.
But yeah, "Get System Trading 'Gold' Ordered By Distance From Me" is your typical space trading game query. I suspect MongoDB can do that in a single call to the DB. RDBMS might require you to do multiple steps to collate that data (or the most horrible of multi-table joins).
You could have a massive relational schema, or you could model those items you talked about as documents in a NoSQL solution. I'm guessing that the ratio of reads to writes is skewed massively to the reads, so this indicates a nicely scaled sharded DB to handle the load.
Solar System: Name, Location, Attached (permanently) Celestials and Constructs. Lookup geo-spatially (3D) would be nice in the DB, to get systems close to you. Seems to map well to a document based storage.
Obviously you would cache it all in memory at run-time (write through for performance), but most DBs can provide that natively these days. What does a typical application store in memory - complex objects. Maybe that could determine what the backing permanent-storage DB should be.
Slashdot Mirror
I would recommend building a 20000ft^2 subterranean anti-methhead-bunker 100ft under ground. This will also allow you to survive Trump.
Install a lift up into a hidden room inside a non-descript looking shed. Obviously the lift will only work via DNA verification anyway.
You should fill the bunker with snakes, scorpions and taratulas, apart from your work area (6x6 ft), this will dissuade people who have cloned you to get into the lift.
As for the work area, I recommend a bulletproof chair that enconses your body as you work.
Cost of production in the pharmaceutical industry has no correlation with the sale price.
This will be sold initially for billions per treatment. Then hundreds of millions. Then tens of millions.
Beneath this, it absolutely will have to make up for the loss of income from other age-related medications and treatments that this would kill, especially if it was available to all. Otherwise it would be an effective way for social governments to deal with the high medical cost of retirement aged people - eradicate the getting old part.
As I wrote elsewhere - immortals will spend their days evading capture by hunter-killer terminator robots.
Nah, best bet is that at 150 you go into clinic for your next rejuvenation treatment unaware of the following intents: you're tranquilised, and then fed into 'the machine' (industrial grinder / furnace). Even better, make it religious, so they queue up for the machine. Sadly some upstart will likely find out and ruin it for everyone else.
I just know that I'll have 40000 project that I've put off for another day that I suddenly feel motivated to finish around that time. Typical.
If rejuvenation means fertility too (thank gawd there are a limited number of eggs in a woman), then birth rate per person may increase over time.
Sure, 1 or 2 children is the western standard these days, but that's because of the small window of opportunity.
There are going to be people, whose children left the nest, who get rejuvenated and who want a new child. If you live to 200, you might have children at 30-40, 60-70, 100-110, 150-160 (a 40 year gap!). OTOH maybe due to housing shortages having your 80 year old child hanging around home might put people off.
If you live to 1000? Even if you settle on a child a century, that's a lot of children.
I'm guessing that floating cities, hyper-stilted cities (shallow seas), transformed deserts, etc, would all occur anyway in the next 50-100 years.
Given a sudden lack of death in the world population (it would take a while in truth) that might buy a few decades on Earth.
It'd be a lot cheaper to allow colonists to take only digital property, personal tech, and some clothes - everything else they can get at their destination. Some of these things could be made in space rather than be lifted too.
Send the people who have lived a life, have extended it, and the price for extending it is being space colonists - Mars, Ceres, Titan, etc. Retire on Earth in a bungalow eating Soy-Lent watching NetFlix, or go into space rejuvenated by 20 years? They can build out space, and when disasters happen, at least the victims had already lived and understood the risk.
Sadly that leaves the rich people on Earth with their life extensions, just sucking up more and more money like the worthless financial black holes they are. They'll still be eating beef and ruling, and trying to stop progressive options like the above.
Most people currently live in a post-inheritance world - either they get funding from living parents, or unless the parents are particularly rich, retirement, health care, care homes, etc, grabs so much of what was built up in savings during life that anything that dribbles down to the children (who are already in their 40s to 60s by this stage) doesn't really pay for a lot so much so that many inheritances jump a generation now.
So IMO if you are relying on an inheritance to get on in life in the future, then you may be disappointed.
Note too that end-of-life treatment is the majority of the healthcare cost over a lifetime for most people. If this treatment can eventually be fairly cheap, then it may be better to always apply it to people rather than let them get close to dying and being costly. In that way, you will be hoping that rapid-death scenarios happen to keep some form of turnover in population - accidents, etc. Maybe older people bored with life will be encouraged to take riskier and riskier holidays...
You can't deny that moving excess people to various floating deadly rocks doesn't solve the overpopulation problem on Earth. The technology will evolve to get to these places over time, although getting it to affordable rates may take a lot longer.
It is likely that the birth rate would continue to drop as well, and with life expectancy extensions - in particular if women could stay fertile for longer (maybe difficult with the limited set of eggs they are born with, but I'm sure they can be kept around too) - it will likely extend even more, as people continue to stay children to older ages (both definitions of 'stay' apply here).
People would still die too, but that would move from ~70-80 years old to ~100-~120 years old on average initially. The concern is that the prolonging therapy evolves over time to be repeatable, and more effective, meaning people will live to a very very long time, and people may already be alive who will benefit from this.
I think there are strong arguments to society being stronger with new blood (to eradicate rich Trumps). So maybe forced exile to the stars once you hit a certain age is an idea. You've had a life, now continue it elsewhere building a new society from scratch, with all that experience you should have gained. And if it all goes tits up, hey, you did live a long time already, don't whine about it (not that your whines will be heard back in our solar system).
Funding mechanisms for the massive cost to society of people hanging around longer will need to be found. Fit for work doesn't mean much work will exist in the future due to automation...
That's if we're not all scrabbling for scraps in a post-Trump nuclear winter.
Yes, take it or leave it.
Another thing Uber drivers can't choose.
How about you reply to the points raised instead of avoiding them?
The situation is that the level of Methane in the atmosphere (net of new methane production/emission and methane breakdown) is going up significantly, and there's a lot more waiting to be emitted.
What do they say in the paper about when the 'modern period' is. For example, is it post-industrial average? Average between 1950-2000? Average between 1000 and 2000?
Additionally it's only the summer warning we care about when we consider maximum absolute temperature - so that's 2-6C - and it was highly localised. Global temperature averages during the HCO were still below today's temperatures (but maybe still above the 'modern period' temperatures).
Regardless, that doesn't mean that during the warm period the bogs in Siberia weren't emitting a lot of methane during the summers and trapping it during the winters, so that a lot of the currently trapped methane is actually more recently sourced. Maybe someone's done some research here. I'd theorise that one reason Siberia was so much warmer during the HCO compared to globally was that there was a local source of warming gases being emitted contributing to the warming.
Well yeah, it's hard to argue against that level of incompetence (that's exactly the case of being hired for a skill and then not having that skill). Luckily there's code review and on-the-side feedback to the manager, etc.
Most suicides are often cries for help at some level or another. The guy probably didn't want to die but felt there was no other path forward.
The fact that details about the employee's status at work are in the story are a major issue, IMO, a massive breach of employee confidentiality.
Sheesh creimer, you should have parallelised that script in your free time and run it on the non-existent compute cluster ... blah blah blah.
It's the jobs without slack time where the mistakes get made (at all levels). Let the employee kick back occasionally, surf the web (hell, reading technical websites is hardly the worst thing you can do in a technical role), do things safely.
And hell, if your manager has told you to only do one task/story at a time, then who am I to say you shouldn't!
Only do the things in (3) that will help you get a new job.
The EIP will not be "Just do X, Y, Z", it'll be a weekly-reviewed self-documented long list of things to be attaining. If the company is reasonable, it will be doable. If they want you out, it won't be - so just concentrate on the things that you like the sound of the most, and avoid the soft-skills crap that is hard to quantify.
If the cause of lower performance is transitory (say, a year long divorce/house move/depression type thing, and the employer is still being harsh on you) then it can be useful to switch job anyway - new jobs are more interesting, learning opportunity, no historical weight, often little legacy crap to deal with - just concentrate on getting through the probation period and hopefully things will ease up in your life (and the stress-break from changing job and losing the EIP will help massively) and then you can move on and forget the bad year or two.
The biggest issue for an employee is under-motivation and/or procrastination (as in, serious internet addiction level) that is not transitory. In that case, well, yeah - visit all your sites in the evening, leaving the morning at-work surf fairly minimal. Hope the work place blocks sites. Etc.
Or you'll get a team that rotates the lowest performing member, as it might require two reviews in a row to hit EIP.
Shame if that means you get no bonus this year, at least the next four you'll get one. Oh, the company did great this year and the bonus is 3x bigger than normal... oh, you've left?
Yes, small teams that work together, who own their own projects, where the projects don't get large (create new projects for new functions) and who aren't held back by external forces as long as they generally follow some basic rules (language, db, api structure, documentation, builds, and so on) generally can get things done.
Super-large old monolithic architectures that have been appended to over many years and now have a team of 30+ basically maintaining it and desperately splitting the tangled code into seperate services talking via RMI to keep development time down, until they hit serialisation versioning hell, and then morale drops and everyone wonders why the front-end ajax interface is rendered in the server side via some weird codified templating system that results in tears instead of hiring people who know Javascript for the front end and trying to do things simply, cleanly and concisely... well yeah, that can get skilled people down.
The first case - you have a team owning N microservices. Team gets too big - the split is easy (well, easier than the second case of having separate teams own parts of the same monolithic codebase), two smaller teams, each with N/2 microservices. Best keep some FE and MW on the same teams though, don't go the route of FE team and MW team, that way leads to more intra-team communications.
Using your example... that depends on whether the programmer is in a role that should be talking directly to the database, has self-identified (e.g., at interview) as knowing SQL and programming language interfaces to it, or has received training in-house to that level via whatever means.
Maybe the symptom isn't a bad programmer, but an in-house process that doesn't work - in this case maybe the company has an in-house DBA team that does DB programming work (and teams that create microservices that interface with the DB), but they are overloaded or don't respond to work tickets. The programmer has just tried a workaround to get something going rather than being blocked by the process for 4 weeks.
(yes, I know that any reasonably experienced programmer should know SQL to some level, but these days it's very easy to go years and years without touching it directly)
Yup, improvement programmes usually exist to document the failure of the employee to meet the demands of the programme, which are set to levels that can't be achieved day-in, day-out over the programme period. Obviously if there is an external issue creating the employee's problems, the programme simply adds stress to the situation they are in rather than even being anything like being a helpful assistance through a temporary situation.
It's usually only when that employee eventually leaves and finds another job that they realise the expectations of productivity from the previous role/programme were not attainable.
At the root there is always a bad manager.
1. The supermarket's name is the full name of the country Iceland, and that's that. It's a source of mild amusement in the country to deliberately confuse the two, especially with the company's adverts which use "Mum's gone to Iceland" (because Dad didn't give her enough money to go to Waitrose, I presume, and other misogynistic themes).
2. But in English, not Icelandic.
3. And also the supermarket started off (and still mostly is) a specialist in low-priced frozen foods - hence the name - it wasn't named after the country.
4. The supermarket is enforcing its trademark to stop companies from Iceland use 'Iceland' in their name.
5. The country believes that this is unfair.
6. Maybe the country should consider some more exciting branding around volcanoes and rifts for their companies. 'Horsemeat Iceland' is all very well, but "Erupting Mid-Atlantic Ridge Horsemeateries" sounds better.
But those three calls in an SQL DB might map to the same single document in a NoSQL DB! Indeed that's one of the reasons for transactions in an SQL database - the tabular structure with fixed columnar schemas pretty much requires transactions for safety.
Maybe you only care about eventual consistency too?
What sort of transactional consistency do you require?
Do you care if it takes a short period to replicate across the cluster before it can be read again? NoSQL solutions include options, if you need that (e.g., i don't care, i want a quorum agreement on the read, all must agree (read from master, enforce writes through master), etc). Indeed these options are often what distinguish one NoSQL solution from another.
Are you only modifying a single document? Then you can do that atomically. Remember that document may represent a lot of tables in a RDBMS.
And maybe this use case is simply not suitable for a document database. RDBMS is great at these things - it just isn't great at some things NoSQL is great at.
Why are hundreds of people working on the same objects directly? That's screaming for a microservice interface on top for the 95% who are doing the same operations. And then suddenly the underlying system doesn't matter.
Most NoSQL solutions have a structure to the documents (because in the end they're serialised forms of Java/C#/etc objects), it's just that it isn't columnar. There can be arrays, inlined sub-objects, etc. And you can set indexes on these deeper aspects, and so on. The DB is optimised for tweaking at the object level of course, and locks at the object level (but doesn't provide multi-object transactions out of principle).
Some NoSQL solutions add some very cunning features to how you can define the structure of the data, you can do some funky things with Cassandra's slices, for examples (although it's been some time).
Exactly. If your company can afford a DBA team, then Oracle is an option. This will likely keep the money rolling in to Oracle for the foreseeable future.
If your company can't afford a DBA team, then you really need to look elsewhere, where-ever that may be (IMO PostgreSQL and Cassandra, maybe MongoDB, maybe ElasticSearch stack) and do a short period of trialing / proof-of-concepting to see what works best. However in this case one suggested recommendation is that you choose ONE company-wide SQL solution and ONE company-wide NoSQL solution, and only allow exotics on a case-by-case basis when the need is demonstrated.
TBH MongoDB 3.4 has graph queries. So assuming Solar Systems are linked by 'trade routes' or 'warp jumps' or even just linked to all systems within X light years, you should be able to use that effectively for route planning, getting all near systems, and so on, without a complex 3D geo-spatial lookup.
But it is application specific, without knowing the requirements, who knows what the use cases are.
But yeah, "Get System Trading 'Gold' Ordered By Distance From Me" is your typical space trading game query. I suspect MongoDB can do that in a single call to the DB. RDBMS might require you to do multiple steps to collate that data (or the most horrible of multi-table joins).
You could have a massive relational schema, or you could model those items you talked about as documents in a NoSQL solution. I'm guessing that the ratio of reads to writes is skewed massively to the reads, so this indicates a nicely scaled sharded DB to handle the load.
Solar System: Name, Location, Attached (permanently) Celestials and Constructs. Lookup geo-spatially (3D) would be nice in the DB, to get systems close to you. Seems to map well to a document based storage.
Obviously you would cache it all in memory at run-time (write through for performance), but most DBs can provide that natively these days. What does a typical application store in memory - complex objects. Maybe that could determine what the backing permanent-storage DB should be.