![](https://i.imgur.com/9UQ54uc.gif"){kind=small}
The question is: Let's say we have a user table where users are stored. In this table, each user takes up one row. Now, let's assume we have a products table where the products belonging to each user are stored. In this table, let's have three fields: user_id, product_id, and product_name. Let's imagine that a user with user_id 1 has 10 products. In this case, there are actually 10 rows for this user. When we consider that there are millions of users and each user may have tens, hundreds, or even thousands of products, this would result in billions or even trillions of rows.
Should tables with this kind of one-to-many relationship be maintained with foreign key relationships or should each user's products be stored in just one row using a hashtable? In other words, there will be two fields: user_id and product. The product field will be a hashtable containing product_id and product_name keys. This way, all data related to the user can be stored under the product field within the hashtable.
Or how else can this be done? It is suggested to perform data cleaning at certain intervals to avoid having too much data. This could work in a product scenario; for example, when a user purchases a product and a year has passed, that data may no longer be needed. However, in a Tinder-like scenario where there is a swiping action, if there are two fields in the table called swiper and swiped_user, every user swiped by another user will generate one row of data. This could result in a lot of rows. We cannot perform data cleaning in this case because if a user swipes left on someone, they should not be matched with that person again. To prevent having too many rows here, we can create a hashtable field named swiped_users. Two keys, swiped_user_id and swipe_direction, can be provided, and all data related to one user will be stored in one row within one field, rather than multiple rows.
Should tables with this kind of one-to-many relationship be maintained with foreign key relationships or should each user's products be stored in just one row using a hashtable? In other words, there will be two fields: user_id and product. The product field will be a hashtable containing product_id and product_name keys. This way, all data related to the user can be stored under the product field within the hashtable.
Or how else can this be done? It is suggested to perform data cleaning at certain intervals to avoid having too much data. This could work in a product scenario; for example, when a user purchases a product and a year has passed, that data may no longer be needed. However, in a Tinder-like scenario where there is a swiping action, if there are two fields in the table called swiper and swiped_user, every user swiped by another user will generate one row of data. This could result in a lot of rows. We cannot perform data cleaning in this case because if a user swipes left on someone, they should not be matched with that person again. To prevent having too many rows here, we can create a hashtable field named swiped_users. Two keys, swiped_user_id and swipe_direction, can be provided, and all data related to one user will be stored in one row within one field, rather than multiple rows.