Question: I recently learned about normalisation in my informatics class and I'm developing a multiplayer game using SQLite as backend database at the moment.

Some information on it:

The simplified structure looks a bit like the following:

```
 player_id |  level | exp  | money | inventory
---------------------------------------------------------
    1      |    3   | 120  | 400   | {item a; item b; item c}

```

Okay. As you can see, I'm storing a table/array in string form in the column "inventory". This is against normalization.

**But the thing is: Making an extra table for the inventory of players brings only disadvantages for me!**

* The only points where I access the database is:
	+ When a player joins the game and his profile is loaded
	+ When a player's profile is saved

When a player joins, I load his data from the DB and store it in memory. I only write to the DB like every five minutes when the player is saved. So there are actually very few SQL queries in my script.

If I used an extra table for the inventory I would have to, upon loading:

* Perform an performance and probably more data-intensive query to fetch all items from the inventory table which belong to player X
* Walk through the results and convert them into a table for storage in memory

And upon saving:

* Delete all items from the inventory table which belong to player X (player might have dropped/sold some items?)
* Walk through the table and perform a query for each item the player owns

If I kept all the player data in one table:

* I'd only have one query for saving and loading
* Everything would be in one place
* I would only have to (de)serialize the tables upon loading and saving, in my script

**What should I do now?**

**Do my arguments and situation justify working against normalisation?**

Answer: 
There are a lot of possible answers, but the one that works for you is the one to choose. Keep in mind, **your choice may need to change** over time.

If the amount of data you need to persist is small (ie: fits into a single table row) and you only need to update that data infrequently, and you don't have any reason to care about subsets of that data, then your approach makes sense. As time goes on and your players gain more items and you add more personalization to the game, you may begin to push up against the limits of SQLite, and you'll need to evolve your design. If you discover that you need to be able to query the item list to determine which players have what items, you'll need to evolve your design.

It's generally considered a good idea to get your data architecture right early, but there's no point in sitting in meetings today trying to guess how you'll use your software in 5-10 years. Better to get a design that meets this year's needs, and then plan to re-evaluate the design again after a year.
The reason that you use any technology is to leverage the technology's advantages. SQL has many advantages that you seem to not want to use, and that's fine, if you don't need them. In Neal Stephenson's *Zodiac*, the main character mentions that few things bought from a hardware store are used for their intended purpose. Software's like that, too. What counts is that it works, and it works nearly 100% of the time, and it works fast enough.

And yet, I can't help but think that someday you're going to have some overpowered item released into the wild, and you're going to want to deal with this problem at the database layer. Say you accidently gave out some superinstakillmegadeathsword inventory items that kill everything within 50 meters on use (wielder included), and you want to remove those things from play. As an apology to the people who lose their superinstakillmegadeathsword items, you want to give them 100 money for each superinstakillmegadeathsword you take away.

With a properly normalized database structure, that's a trivial task. With a denormalized structure, it's quite a bit harder and slower. A normalized database is also going to be easier to expand on the design in the future.

So are you sure you don't want to normalize your database?