Oh yeah, I'm saying that relational databases push you even more to assign IDs to every miniscule piece of information, especially if you're following best practices (3NF or similar).

For example, you're not supposed to say that a user has a list of interests, you're supposed to say that there's users with a user_id and then there's user_interests with a user_id and an interest_description, so two separate tables.
If those interests can be indexed, then you'd want three tables:

• users(user_id)
• interests(interest_id, description)
• user_interests(user_id, interest_id) (N-M-Mapping)

I mean, this might not be the best example, as it kind of makes sense to not always load the user interests whenever you do anything with the user, but yeah, the point is that you're supposed to split it up into separate tables and then JOIN it as you need it.

With these RDBMS, your entire data loading logic is supposed to happen in-database, so you pretty much need to chop the data into the smallest possible parts and assign IDs to all of those parts, to give you the flexibility to access them how you need to.