What is the recommended way to store lots of user meta fields? (All generic small data fields on a user such as: eula, role, newsletter, temp cached data, consent to this/that, turned on setting X and Y, etc). Usually in my old MySQL projects I hate having these as individual columns, as it becomes manageable and keeps on growing, while most of the values/columns are just

null

for 90% of users. — So I've usually stored this as a JSON column in MySQL, which did work great back then. But with Prisma, graphql and graphql-bindings I see that this JSON approach would lose a lot of the power of graphql, making me have to do lots of manual validation on this json object. So I'm wondering how to best deal with lots of these meta values in Prisma?

type User {
  id: ID! @unique
  email: String! @unique
  password: String!
  meta1: Json! # ← My traditional approach, any data, any structure)
  meta2: UserMeta! # ← Thinking this might be better?
}

type UserMeta {
  role: UserRole!
  newsletter: Boolean
  # …etc, lots of other fields
}

enum UserRole {
  MEMBER,
  SUPER
}

But I still kinda dislike that the

UserMeta

might grow to 20+ columns, and most of those columns will be

null

or the default value for most users.

I would like to know too. I think the json complicates validation more than just having the UserMeta type.

If you have lots of null or default values for some users but not all, then there is a chance that your users aren't all the same. You should think about identifying whether or not you can generalize all users that have null on fields

A

,

B

,

C

for instance and make them subtypes of user (say

BasicUser

). Additionally, make

User

an interface,

That is a good point Arnab, didn't think about that approach. Might start doing that as things start to scale up a bit. At the moment it's only 2-3 fields, but from experience it quickly starts to add up as the project ages.

Also, consider if you ever need to query/filter these fields. I don’t think filtering is possible with the JSON approach at least right now

It's not just about scaling. It's also about being specific inside your domain, which is one of the biggest things that GraphQL brings to the table. The strong typing is meant to be used to describe things exactly as they are

Very valid points guys. Think I just have to get out of my old ways of thinking, Thanks! 💪