> No UI for traceless edits and DB password split in three parts like nuclear launch codes.
That works well for nuclear launch codes because the only time you need to combine the split parts to make the full launch code is when you are actually going to launch (and perhaps during scheduled readiness tests). This should be fairly infrequent.
For a database, you'll have processes that frequently need access. For persistent processes, you'll need to have the reconstituted password available at least whenever the persistent processes start. If you architecture has dynamic processes that access the database (e.g., you have something internal working over a REST or CGI or similar interface, that starts upon receiving a request), you need a way to get the password to them.
Most solutions I've seen for supplying the full password in these cases have been fairly easy for someone with admin access to the machine running whatever it is that holds the full password and/or to a machine running one of the processes that needs to full password to get a copy of the password.