Hardcoded strings are not a problem. Let them be.
What you should have though is functions wrapping the queries so each of the identifiers is only used once in the code.
If you have more than one place where you need the strings, creating constants for them makes sense, because the compiler will make sure that they are consistent. But if you have one place in code and one place in the database, the compiler won't be checking anything if you make constants, so the only thing constants will give you is more lines of code, (probably) extra source where the constants will live and more places to change whenever the constants need to change (because you want to change both the value and the name of the constant every time; in this case you need to know the actual string, so letting the symbolic name and text diverge would make things worse). And they'll win you exactly nothing, because checking against the database (or configuration or whatever) will still only happen in tests and/or at runtime.
The usual advice against hard-coded values is about values where the meaning of the value is not obvious from the value and can be made obvious by introducing a symbolic constant or constants that appear in multiple places where have to be kept consistent. Meaning of keys in configuration or property table is obvious from the value and usually don't appear in many places, so the advice does not apply.
Or, more succinctly, if you have more descriptive name for the value, or if you can make the actual value strongly typed, make a symbolic constant. If the symbolic name would derive from the value, don't.
… you seem to have the later case.