If you are creating a web api, I find that it is best to think in terms of documents (see Webber 2011); URI identify documents, and method-tokens identify the operation that we want to apply to a document.
Unsafe operations (POST, PUT, PATCH, DELETE....) are requests that we change the contents of a document. Key idea - when the contents of the document change on the server, we also want to invalidate any cached copies of the old version of the document. RFC 7234 describes the mechanism for this.
But the short version is: when we respond to
POST /foo with a non-error status code, that tells general purpose caches that the representation of
/foo may have changed, and therefore previously cached copies should be invalidated.
On the other hand, an error response (4xx or 5xx) indicates that the representation has not changed, and therefore the cache can continue to provide the copy of the document it has.
Therefore, based on your description, I would expect that you would be using
POST /foo, where
/foo identifies a document that includes the result of your calculation (ie, the data in your second table).
On the happy path, where you are able to compute and store the data in your second table, then a 200 response is fine.
For the case where you cannot, because the remote system doesn't have the information you expect... That's trickier. 404 is certainly an option if the identifier is the problem (the fact that the missing data is in a different database really doesn't matter), 403 "I understood the request but I'm not going to do it", 409 "the resource is in the wrong state to do that" is another possibility.
These are all variations of saying "the request was wrong".
The possibility that I think is most interesting is 503 "I understood the request, but I can't fulfill it now. Ask me later." With the appropriate Retry-After headers, you can communicate how long the client should be expected to wait.
It might even be reasonable to use a 200 here; when your document has information in it that says something like "we couldn't find the location information as of [time]", because the failed attempt to look up that data also changes that "as of" time.
200 means that the request was understood and processed correctly - that doesn't necessarily mean that the processing took the "happy path".
In short: "it depends".