Bonjour , je vais reposer un post que j'ai mis hier en anglais désolé.
Donc ici je vais parler de concept objet et base de données.
Plusieurs solutions s'offrent à notre équipe de développement . (je travaille avec des américains).
Le site concerne des millions d'utilisateurs.
Les utilisateurs seront de trois types
- Business
- Artist
- Fan ou Autres
Sachant que chaque type a ses caractéristiques et que chaque utilisateur a des champs communs.
Un utilisateur a forcément un username , un password , email , adresse...
Un artist joue d'un instrument , a un genre de musique ....
Un business a un site internet , fax , hours of operation , method payments.....
Un fan a un artiste préféré ......
Donc on voit bien que chaque type d'utilisateur hérite d'une entité commune (abstraite ou non ..) user.
Comment implémenter cela de la meilleure manière tout en prenant en considération que la base de données sera gigantesque ! Que l'on veut optimiser l'espace disque , les temps de requetes ( les jointures attention) et surtout pouvoir facilement modifier le modèle.
J'ai lu cet article
une table par entité? une table unique ?
Mon collègue suggère d'utiliser une unique table d'utilisateurs avec tous les critères possibles avec un champ qui indique le type et de laisser vides les champs inutiles (un artist n'a pas d'hours of operation . Un business ne joue pas d'instrument)...
Il dit que laisser NULL ne prend pas de place alors qu'utiliser différentes tables va forcément prendre plus de place (duplication des ID integer a 32 bits fois A million.... (dans users et business , dans users et artist et eventuellement dans users et fans)) et que les temps de requetes seront plus longs (JOINTURES).
Est ce que laisser NULL prend de la place? Si non alors ça semble plus optimisé au niveau temps de requête et espace disque mais qu'en est-il du modèle? Est ca facilement modifiable si demain nous avons un nouveau type?
Il suffirait d'ajouter des champs dans la table users?
Merci beaucoup pour votre aide.
Partager