Indie-Resource.com

I want to have an inventory that is for trade items. But I kind of hate adding tons of entries to the database. I was thinking of just having one long number, like 123456789, using each digits position to indicate an item and how much (up to nine units). I then split it down into individual numbers.

Does it matter which way you do it? One big number or multiple entires in the database For me, atleast, it's tidier.

Parsing one large field would be orders of magnitude slower than having multiple entries. Don't worry at all about having tables with plenty of entries! That is what databases are made for! You would have to have the most popular PBBG on the net before you could even imagine beginning to stress out a solid RDBMS like MySQL, PostGreSQL, SQL Server, etc. Concurrent connection counts and length of held connections are much more important than how many entries you have.

For an inventory table, you would use a many-to-many relation, which takes the form of an intermediate separate table. Players each have their own Player ID, items have their own master IDs on the master item tables, so you take both of those and record them into an inventory table with another field to represent the quantity of said item. Each player will likely have many different records in the inventory table, and each master item entry will likely appear many times, owned by many different players.

Thanks, Jack! Really I don't want to go a complicated inventory at the moment, so I'll just have something like 'slot1' 'slot2' etc added to the characters database entries. It'll be a fixed max size inventory (which in a way, even wow does that).

You're really going to want to avoid unconventional ways of organising data in your database, or even within your hard-code because as you start out on a project that will take you some time, you'll want to get some help, whether it's other team members or online support, and when people look at the code or organisational structure of your database/code, they're not going to understand it as well as if you'd used conventional methods of sorting everything.

What Jack says is good!

The way my inventory system works is as follows:
-> I have an "x_users" table that contains important information about the players, including their unique ID (Primary and auto-incremented key)
-> I have an "x_p_Inventory" table which holds all the players items within the game. I limit how much someone can hold using in-code restraints.
-> I have an "x_items" table which contains all the items within the game. Each item has a unique ID to identify it as a separate entity.

My x_p_inventory table contains few columns, the most important for this topic are the users unique ID and the items unique ID.
With these two fields I can draw in a simple inventory to the game-world, using a loop to display all items that are held by the current users ID.

This relationship is known as a One-to-Many relation in the database world, and is usually the aim of a process called 'Normalisation'.
One-to-Many can be described by looking at how the two inventory fields interact.
One-player has-many items.
(This is because each item, when created, has it's own unique identifier below it's master ID that describes what item it is.)

(Don't worry if this doesn't make sense, it's just additional information!)

Corinthius~