When doing database development disk space is not your consideration. Disk space is cheap. The problem is the size of the data table, and how that affects performance. I'm going to use some SQL Server parlance here, because I do not know what backend Blizzard is using (likely Orcale but who knows).
A database stores data in chunks, referred to as pages. The size of the chunks will vary from vendor to vendor. For SQL it is 8k. Whenever you access data, a page is pulled from memory if it cached, or disk if it is not. The number of pages that make up the table directly affects how fast you can access it.
Now, take the example 1024 bytes per row. That is a little under 7 rows per page. Take Blizzard's approach. If they use a lookup table with a character ID and an item ID (seems the most likely approach) that is 124 bytes. Less if they use unsigned 32-bit integer values.
The smaller they keep the rows, the more rows they can fit per data page, which means fewer page reads to fetch the data. It could also mean -- with a sufficiently beefy server -- that most if not all of the data could remain in memory. This is critical, as accessing data in RAM is hundreds if not thousands of times faster than accessing it from disk.
Now, you could index the table, likely clustered on the character ID. But if you have 1024 bytes of data then you start to get frequent page splits. Page splits murder performance. The more rows you can stick in a page, the less likely it will be to split, and the faster read/write operations will perform.
So yeah, sounds easy, but trust me, it ain't. Especially considering this is a game, and any kind of response time greater than one to two seconds is going to be considered a fail.
Edited by Arcana on 8/18/2011 12:22 PM PDT