#Database related questions

1 messages · Page 1 of 1 (latest)

polar field
#

Good afternoon, I have a question about databases. I know it's something completely unrelated to programming but it's something important.

From what I understand when it comes to working with common attributes of something they are put in the same entity. But when you have common and uncommon attributes at the same time of the same thing, they are put in independent but related entities.

My big problem is that I have a main entity that represents my user and 2 that represent sub types of the main one, for example an administrator and a programmer, both are users. But they have different attributes, so it is not possible to have a single entity.

But my question is how do I make the relationships? Since a user in my structure can only be associated to one sub type at a time. That is to say, the reference of a user account cannot be in both sub entities at the same time. Only in one of them at a time, there is my problem.

I don't know how to do this in a proper and functional way, without having duplication problems.

fierce elk
#

might want to use nosql

polar field
fierce elk
#

models as in documentation?

polar field
#

let say we have a users magament system

#

users can be have a role and can be considered as admin and other role at the same time

#

but an admin and another role, dont sahre same properties. So they will be independent models / entities

fierce elk
#

sounds like your role doesnt have a strict scheme of properties on it

#

assuming you're working with some object based database, whats difficult about representing your roles as objects?

polar field
#

exactly
The problem is that I can't store all uncommon attributes in the same entity. Because that breaks the principle of single responsibility in case of models and other things in terms of databases.

So I must have a main entity that has the common attributes like uuid, name, etc etc. And then an entity that represents for example the moderators, because they will have specific attributes only of them and that would not have an accountant.

Then I must find a way to associate the sub types of accounts to each user, but knowing that this one can have many sub types at the same time. But within each sub type / entity the same uuid cannot be duplicated.

fierce elk
#

ah wait i get it

polar field
#

i take some time because i translated to english, so you understand exactly what i want hehe

#

thanks for helping tho, because this is not something really easy

fierce elk
#

sounds like a map<role id, role data> high level

polar field
#

because you have to think not only about how to do it, but also that it meets standards, that it is scalable but functional at the same time.

polar field
#

my idea is to make use of NoSQL references

#

so each user would have something like List<Role-Id>, which then using like a join function will be able to return the associated data in a select operation for example

fierce elk
#

i have no idea what those are, i only know mongodb allows you to store lists so why cant you

#

well not a map :/

#

well a map is just an object so

polar field
#

references is similar to a pointer, it points to something else in another place

fierce elk
#

im imagining it as

entity {
  name: stuff
  roles:
    {
      admin: {
        admin-data: "aajaghakjhgsuyajhbsa"
      },
      default: {
        id: "Abahgz"
      }
    }
}```
polar field
fierce elk
#

id say "roles" is a reference?

#

i have no clue

polar field
# 
user: {
  name: stuff,
  roles: [
    "uuid-1",
    "uuid-2",
    "etc"
  ]
}

roles: {
  "uuid-1": {
    // role data here 
  },
   "uuid-2": {
    // role data here 
  },
}
#

thats how references work

#

user collection just store the id of the role the user has, in another collection you just store the roles data itself

fierce elk
#

well store data is per user so why not store it in the user

polar field
fierce elk
#

dont think that has anything to do with srp

polar field
#

which says common attributes goes in same entity, while not common attributes goes in independent models

#

i ask this because my teacher gots mad because i bring him just a single collection with all data inside it. He blame too much hahaha

fierce elk
#

i mean the user is the entity

#

would just store role data inline with the user as it wouldnt make sense otherwise, not in terms of logic, nor performanc

polar field
#

Something similar happens in machine shops with cars, each type of car is a specific entity since each type has independent attributes, which one has and others do not.
For example, a motorbike and a car both have the same colour and type of paint, but a car has doors and a motorbike does not. That's what I'm getting at hehehehe.