Although you can get pretty sophisticated with the display part, like a financial (stock or currency) info site that lets the user know the price history and trends, or like an online catalog that tells the user a lot about the item, or even keep it down to a simple price list, that's not the immediate question here*.
What we need to know is how the prices, etc., are going to be set in your "dream" version of the application. (Okay, maybe not your dream version -- there's no easy way to have the server read minds yet.)
You've said that posting the prices manually is (or would be) tedious. How are you imagining that happening right now? And what would the process look like if you had your
druthers? Would you (or a team of logged-in "admin" users) be doing the updates, or do you envision an automated process (where the server would "watch" the market for in-game trades)?
The manual process can be easier than you might imagine -- just type in a new price on the web page and hit "Enter" to change an existing price, and a background XMLHttpRequest will update the value on the server. Deleting items is just as easy if you need that option. Adding items is only a little more complicated, but that's really only because you'd need to type or select more information (the game if you are handling more thn one game, the item category, the item name and the price). All of this depends on using JavaScript in the browser (as well as a database and a server-side scripting language like PHP), but it doesn't mean having to manually edit your HTML or even loading a separate form to make an update -- it can be as easy as using a spreadsheet. If that's all you want, then the implementation isn't too terribly difficult (although it may be way beyond anything you've done before, it really isn't that hard to do).
If you are looking at a completely automated process, then things get a whole lot more complicated. Not impossible, just a whole lot more complicated. Sometimes you can use a game API (Application Programming Interface -- in this case, a way to get at game data directly); sometimes you have to load web pages and look for gold among the gravel. A word of warning here, though: something like this can take more time and resources than you'd be allowed to use with your hosting plan if you're using shared hosting of any kind; it often makes more sense to set up your own machine (at home) to do the heavy lifting, then post the raw updates to your server periodically -- even the crappiest old off-lease piece of junk you can find on the used market can be set up to do something like that, and it will spare you having to worry about resource limits on your web hosting server.
I hope I've given you enough information to ask a better question. We really do need to know a lot more than you've told us so far before we can give a constructive answer.
* You do need to plan all of this as well; it will affect your front end (the web page the user sees), your "middle tier" (the code that sits between your user and the database) and your back end (the way the data are stored). Some things are easy to add later on with a relatively low cost in development effort (like catalog descriptions); some things need to be there pretty much from the beginning if they're going to be of any use.