School database structure

[florian-lefebvre]

Je propose qu'on parte sur le modèle suivant (on ne parle pas ici des join tables) :

graph LR
    User <--> Member <--> School

Loading

Les modèles ne prennent pas en compte les PRs en cours qui peuvent modifier certains schemas.

type UserRole = 'user' | 'developer' | 'admin'

interface User {
  id: number
  email: string
  password: string
  rememberMeToken?: string
  roles: UserRole[]
  accesses: HasMany<Access>
  members: HasMany<Member>
  createdAt: DateTime
  updatedAt: DateTime
}

type MemberRole = 'student' | 'teacher' | 'parent' | 'staff'

interface Member {
  id: number
  firstName: string
  lastName: string
  birthDate: DateTime
  roles: MemberRole[]
  user: BelongsTo<User>
  school: BelongsTo<School>
  createdAt: DateTime
  updatedAt: DateTime
}

interface School {
  id: number
  name: string
  members: HasMany<Member>
  contact: {
    email: string
    phone: string
  }
  address: {
    street: string
    city: string
    state: string
    zip: string
  }
  rne: string
  createdAt: DateTime
  updatedAt: DateTime
}

J'oublie sûrement plein de champs, n'hésitez pas à faire part de vos idées et je mettrai à jour ce message.

cc @op-ent/backend

[Micorksen]

Pour vérifier les RNEs, je te laisse voir mon issue #11.

[florian-lefebvre]

On verra lors de l'impémentation, là on est juste sur un schema théorique. Tu sais s'il existe une API de l'état avec tous les RNEs ?

[Micorksen]

Hello, oui j'ai même fait l'issue pour inclure l'endpoint.

[NonozgYtb]

Je propose une amélioration qui inclus les académies (car un ENT peut comprendre plusieurs académies)

interface School {
    // On garde le reste
    national_id: string // Pour l'internationalisation, je pense que "national_id" est plus pertinent que RNE mais cela ce résume au même, exemple : 0120000A
    academy: Academy
} 

interface Academy {
    id: string // exemple : 3df8e3284e39b
    name: string // exemple : "Académie de Ville"
    national_id: string // exemple : "ac_ville" (utile par exemple pour le domaine, la route, le portail spécifique de l'académie
    schools: HasMany<School> // Il serait peut-être pertinent de relié dans l'autre sens mais à mon avis, pas obligatoire
    members: HasMany<Member> // Je le mets car c'est logique mais cela ferait avec une mise en prod. beaucoup d'entrée, complexe et lourd (niveau performances) à manipuler.
}

Aussi, quel est le modèle de Access ?

[florian-lefebvre]

https://github.com/op-ent/api/blob/main/app/Models/Access.ts mais je l'ai pas spécifié parce que ça ne concerne pas les établissements

[florian-lefebvre]

Quel est l'intérêt de stocker l'académie ? Je veux dire, qui va avoir accès à l'information (usecase) ?

[Micorksen]

Quel est l'intérêt de stocker l'académie ? Je veux dire, qui va avoir accès à l'information (usecase) ?

Bah pour trouver les établissements par académie.

[florian-lefebvre]

J'ai bien compris mais en pratique, qui va chercher au sein d'op-ent les établissements par académie ? En sachant qu'un utilisateur n'a accès qu'aux établissements dont il est membre.
Si vous avez des vrais usecases, dites moi, je suis pas du tout contre mais je préfère implémenter que ce qui est utile

[MRakox]

Les colonnes createdAt et updatedAt sont inutiles pour la plupart des modèles...