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: 
Are you saying that you think parsing a string out of "inventory" *doesn't* take any time or effort? Because everything you need to do to store/retrieve inventory items from a sub table is something you'd need to do with this string, and with the string you don't have any database tools to help you do it. 

Also, if you had a separate subtable for inventory items, you could add and remove items in real time, meaning that if the app crashes or the user disconnects, they don't lose anything.
No, your arguments aren't valid. They basically boil down to "I want to do all of this processing in my client code instead of in SQL and then just write it all to a single field" because you are still doing all of the *exact same processing* to generate the string. By doing this you are removing the ability to easily load a small portion of the list and losing relationships to the actual `item` table which could contain more information about the items (I assume you're hard coding it all based on names instead of using internal item IDs which is a really bad idea, imo).

Don't do it. Long term the approach you are wanting to take will generate a lot more work for you as your needs evolve.