I wouldn't consider that a good, scalable solution, no. The client should not directly query the database on the server, because that will overload the server/database with requests as you increase in scale. You also should not rely entirely on the server for position information as it will create an unpleasant experience for the client.
Multiplayer games in general typically employ client-side prediction to cope with the latter situation. This involves having the client maintain a local copy of its simulation state. When a player issues a command to the client, the client transforms that into a request for action which it sends to the server.
While the client waits for the server to confirm that the action is legal, it assumes the server will say yes, and updates its local state accordingly. This local state is used to render and subsequently is what a player will base subsequent input on. This allows for a responsive-feeling client (if you are constantly waiting for the server before moving at all, the client will feel sluggish and laggy even under ideal network conditions).
Eventually the server will get the request, process it, and can send a response to the client in the form of updated game state or some such -- the client, when it receives this, simply updates its local state to match, since the server is the authority. You will probably also want to employ smoothing between state updates to help hide unpleasant latency effects this can cause.
You can find lots of resources for client-side prediction and smoothing via Google or your favorite search engine.
As for the former issue... neither the client nor the server in an MMO should read data from the database constantly. It should keep the data and the game state in RAM locally, and push to the DB in intervals so as to avoid flooding it. See this related question for more information.