I don't want to share the database credentials with him.
If they have access to the client connecting to the DB, you have to. Otherwise, by definition, credentialed access would be impossible.
However you obfuscate the connection phase, once the connection is established anyone with access to the source code may hijack it however s/he desires. I don't think that even encrypting the whole modeling class would be enough.
This is particularly evident using the deprecated MySQL functions: once a connection is established, any other part of the code may issue a query and have it executed in the context of the connection, with no longer any need to know the credentials. But unless you do things very carefully (and, I suspect, depending on the attacker's ability, even if you do), the same will hold true with mysqli, PDO, and so on.
What you can do is:
limit privileges on the database to the barest possible minimum. This should always be done, BTW, because you never know what vulnerabilities might be in some code, yours or somebody else's that's connected to yours (libraries, plugins, ...), and who could thence gain access to the application.
limit connection IP to that of the client. Another thing you should always do whenever practical: there's no reason not to.
move whatever is possible to move into stored procedures and functions.
If you want (and really need) even more control, you need more work:
- instead of using prepared statements (and, BTW, you will now have to have "static" statements - you won't be able to
prepare, say, SELECT {$field} FROM table WHERE id = ? and bind it to id), move the statements themselves
to a thin layer on the database server, passing parameters via (e.g.) JSON.
So what was, say,
SQLExec("SELECT * FROM users WHERE userid = ?", "1")
can become very easily
HTTPExec("SELECT * FROM users WHERE userid = ?", 1);
but now, on the server (you'll need a HTTP server there), a script will verify that the requested query is indeed among the approved queries; and only if so, execute it and return the results. Depending on several factors, you might even be able to pass this as a "performance improvement". On the other hand, the "database" server is now more loaded.
Now the client cannot issue a "DROP TABLE Students;" statement, because this statement is not among the approved statement list.
To generate the approved statement list, you can instruct the server to approve everything and store the queries it receives; you then do an exhaustive review of all the web app, in order to trigger all queries at least once (you probably have a test integration script that already does this, and verifies that results are OK); when you've finished, all the queries just received, and only those, will be considered "valid".
Someone changes a comma in one of the queries in the client code -- and the server will reject the query as unauthorized.
This is in the end equivalent to moving (or duplicating) the relevant application code onto your server, so there might be issues: in effect, you're no longer giving your client the full application.
(At that point you could even replace all the queries in the client code with their, say, MD5 hash. The server does not really execute the SQL sent by the client anyway, it executes the good copy that's present server side for comparison purposes. So sending the query or its MD5 signature is perfectly equivalent).
