If the trade is entirely single-user, then you can build it all into the client.

If the inventory matters, such that you support trade between players/characters, then you need to put it on a server.

And, yes, you never want the user to talk directly to a database; enforcing business rules and authorization is what an app server is for.

So, the easiest way to spin this up is to use some kind of existing web services framework. You then use HTTP (ideally HTTPS) to talk to that "web application."

Interesting web services frameworks include:

- Node.js with

- Ruby with rails

- PHP with recess

- Erlang with webmachine

- etc

These kinds of frameworks can often be backed with a variety of databases -- MySQL, PostgreSQL, Redis, Cassandra, ...

And, no, using an existing, robust database is not "overkill" -- it's a proven pattern that solves a bunch of problems you don't want to solve yourself, like atomicity, consistency, isolation and durability (with different trade-offs for each of the databases.)

And I would do trade/inventory as database transactions. They're not that frequent (how often does a single player trade?) and consistency is more important than millisecond response time for things that affect the economy.

If you have millions of active users, you will have to learn how to scale up such a system, but that has been done before, so don't worry about that now.

Another option would be to go with a platform-as-a-service system like Google App Engine. That can work, too, as long as you're OK with the vendor lock-in that comes with that.

would it be better to access a PHP website that will update the data or an app server that will do the database things?

The reason to use a database is to support "correct" trading and economy, such that users trying to bring servers down won't cause item duplication bugs etc. (This has plagued several MMOs in the past that did trade in-RAM only.)

It's reasonably easy/simple to build a trade system that is transactionally consistent as long as the database lives on a single database server. MySQL, Redis, and all the rest generally support this.

Once you need to scale past what a single database server can support, the approach you need to take changes, and you may need to re-structure your data storage and trade implementation.

For a game that hasn't even shipped yet, sticking with a single database is fine.

Also, if you define one database per world "shard" and one separate database that only contains user/billing information, that will probably also let you scale for a long time, with the limitation that you don't support trade between different shards.

Pleas use a new thread for a new question.