With this kind of set-up you would generally call the the unity app the "client", because it's the part of the system which the end-user uses to view and interact with the world.
Your client would never normally have direct access to the database. This would generally represent a significant security problem. What is more typical is that clients would talk to a dedicated multiuser server application using socket connections (for example, something like SmartFox server, or often - for MMOs - a custom written server app).
It's also the case with simpler database interactions - such as a server-side scoreboard - that your client would never access the database directly, for similar security reasons. Instead, your client (the game) would talk to specially written server-side scripts (eg, in PHP or ASP), which in turn would access the database themselves.
Therefore it's only ever server-side programs that are under your complete control which have authorisation to directly access the databases, and your clients (which are less trusted, because they're in your user's hands!) are restricted to making higher level requests via an API of your own design, which is restricted to relevant commands such as "SubmitScore", and "RetrieveScoreboard" in the case of scores, or things like "MoveToLocation", "TakeItem", "Say Message", etc for a multiplayer RPG.
This multiuser server would then deal with handling interactions in your world, and it would be responsible for interacting with the database behind the scenes to create, read, update and delete information from the DB such as user details and persistent world data.
For this reason, your Unity client need never know about the existence of such things as SQL, tables, records, etc :-) These are all things which should stay on your server, either as server scripts or within your multiuser server application.
).