Learn More
Resend Email
5
b2plane
218d

Lets take onlyfans system for example. They have fans and creators. How is database models supposed to be structured? Whats the correct way.

1) a User model that contains all users of all roles, but differentiates them by Role ENUM

2) a separate Fan and Creator model, each having their own unique attributes, while each extending an abstract base User model class that has all the common attributes that both models should use

The 1st approach is simple but gets very large and difficult to maintain and view all the attributes cluttered in 1 class. Not to mention how some attributes will never be used for a user who registered as a Fan.

2nd approach is more modular and easier to understand and maintain by knowing exactly what attributes to put for each model. However problems occurs when you try to join tables and stuff start to become overengineered

rant
Favorite
Ranter
Comments
  • 8
    218d
    They are running Whoredpress.
  • 1
    218d
    @Demolishun be serious and explain
  • 1
    218d
    As a creator can also be a supporter and each can have multiple projects they create/support the right model would be a user that authenticates with unlimited projects that you either support our create.

    So in terms of tables:
    users
    projects
    project_users - with a role attribute

    That way your normal user is always authenticated and can have many projects to create our support
  • 0
    218d
    @Tamrael what if the only ones who can produce (sell) content are the Creators, while the only ones who can consume (buy) content are the Fans?

    Now you can see how there are gonna be quite a few attributes that the Fans are Never gonna have.

    How would you structure models now?
  • 0
    218d
    @Nanos the biggest difference i forgot to mention is the case where Creators can only create content while Fans can only consume and buy content. Now you can see how both of them might not ever need to have some specific attributes
  • 0
    218d
    Look up BNF
  • 0
    218d
    @Nanos the fans will NEVER be able to become creators. Once you make a fan account you have decided you only want to consume and spend
  • 2
    218d
    @b2plane why limit it like that? I can't think of a good engineering reason, but I can think of lots of edge cases where people would want to do both
  • 2
    218d
    I would make every account a fan and a creator. Like YouTube. And most people just won't touch the upload button.
  • 2
    218d
    I'm not familiar with the system, but bear in mind they may not use a relational db at all - these days a lot of data is denormalized and stored in key value document stores.

    It means you end up likely duplicating a view of data all around the place wherever you need fast access of it - but you gain easy scaling, replication and very fast lookups no matter the size.
  • 0
    218d
    @lungdart it doesnt matter why it works like that. Tell me how you would model the system i described
  • 2
    217d
    Any user stuff I always do something like

    User (generic shit like name, email, password) with its own is
    Then add other tables

    Creator (userId PK FK)
    Fan(userId PK FK)
    Admin (userId PKFK)
    Etc.

    Works fine, though I’m no dba so I’m sure there are better options. And of course it depends on your requirements, but I find it very flexible.
  • 0
    217d
    @ars1 is the User table supposed to be created separately or should it be ignored and it's attributes passed down to its superclass who inherited it and create those tables instead (fan creator)
  • 2
    217d
    I read the first line and i knew it had to be you. Only one person on this app who would be interested in understanding how onlyfans works !

    Lowkey, i love how you are using all the devs here as your free-of-cost advisors posing them as questions.
  • 0
    212d
    @b2plane look up data normalization. It's the theory behind creating stable data schemas
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment