This made me curious. Which would be best in the following scenario: a user table - 3 columns (user, password, id) an item description table - 30 columns (id, name, description, weight, cost, color, brand, class, etc...) let's say we now have 50 000 users and 1 000 items. Each user has on average 100 random items from that list. What would be the best way to store which of these items a user has? Looking at your video I'm concerned that a lookup table that stores the ID from the user table and the ID from the item description table, whilst only having 2 integer columns would grow really big really fast (50 000 * 100) and that must have detremental effects on queries, right? If I create copies of the item description table, it would still be 50 000 * 100 and 31 columns long (30 from item description + which userID it has), that seems even worse from a cache standpoint - but fewer cpu cycles. If I create a table with an ID field and then a string value and fill it with a number series (ie 1,512, 23, 87, 234, 34, 75, etc...) of ID's then I would have to send both that and the entire item description table instead of just the ones that a user has before I begin parsing out the ones that the user has, which seems like an unnecessary load on the network when I only want to send 10% of the item description table and not the whole thing. Or - and I just thought of this: would it make sense to have a separate database per user. Seems clever from a performance standpoint, but...more than troublesome to manage.
