Meilleure architecture - taille d'un document

meijy · Septembre 10, 2017, 2:37

Bonjour,

Je suis en train de développer une plateforme d’emploi et des évènements.

Comme le schéma classique de toutes ces plateformes, les entreprises publient leurs offres d’emplois ainsi que leurs évènements et les candidats postulent ou participent aux évènements qui les intéressent. Les candidats peuvent donner des notes et laisser des commentaires sur les entreprises présentes dans la plateforme (comme le note que l’on trouve sur les applications dans google play par exemple)

J’utilise MangoDB / NodeJS et React pour ce projet.

Vu que c’est ma première application en MangoDB, j’aimerai bien avoir vos avis sur la meilleure architecture de la base de données à mettre en place (performance, scalabilité) parmi ces 2 choix.

Choix 1 : 2 documents: Entreprise et Candidat

Entreprise {
"id" : ObjectID
"nom" : nom de l'entreprise,
"siteWeb" : site web de l'entreprise,
_commenaitre: et d'autres informations nécessaires comme le statut, le nombre des salariés, etc
……
"offreEmploi": {
                "id": 1,
                "Titre": "Titre de l’offre 1" ;
				"Descrption": "Titre de l’offre 1",
				_commentaire: les objets ci-dessous sont des tabeaux qui contiennent les informations des candidats
				"CandidatPostuler[]": ,
				"CanditatAccepter[]": ,
				"CanditatReffuser[]": ,		
				……
                },
				
                {
                "id": 2,
                "Titre": "Titre de l’offre 2" ;
				"Descrption": "Titre de l’offre 2",
				_commentaire: les objets ci-dessous sont des tabeaux qui contiennent les informations des candidats
				"CandidatPostuler[]": ,
				"CanditatAccepter[]": ,
				"CanditatReffuser[]": ,
				....
                },
}				
				
"offreEvenement": {
                "id": 1,
                "Titre": "Titre de l'evenement 2" ;
				"Descrption": "Titre de l’evenement 2",
				_commentaire: les objets ci-dessous sont des tabeaux qui contiennent les informations des candidats
				"CandidatPostuler[]": ,
				"CanditatAccepter[]": ,
				"CanditatReffuser[]": ,		
				……
                },
				
                {
                "id": 2,
                "Titre": "Titre de l’evenement 2" ;
				"Descrption": "Titre de l’evenement 2",
				_commentaire: les objets ci-dessous sont des tabeaux qui contiennent les informations des candidats
				"CandidatParticiper[]": ,
				"CanditatInteresser[]": ,
								....
                },		                
}
}

Candidat {
"id" : ObjectID
"nom" : nom du candidat,
"mail" : mail du candait,
_commentaire: et d'autres informations nécessaires comme le téléphone, adresse, etc
……
"OffrePostuler[]": ,
"OffreAccepter[]": ,
"OffreSauvegarder[]": ,

"EvenementParticiper[]": ,
"EvenementInteresser[]": ,
"OffreSauvegarder[]": ,
}

Choix 2: 4 documents: Entreprise, OffreEmploi, OffreEvenement, Candidat.

Séparer OffreEmploi et OffreEvenement dans le document Entreprise, du coup, il y a 4 documents au lieu de 2: Entreprise, OffreEmploi, OffreEvenement, Candidat.

Quelle sera la bonne solution à mettre sachant que d’après la documentation que j’ai lu, la taille d’un document ne doit pas dépasser le 16Mo. Avez-vous d’autres suggestions à me proposer aussi.
Merci beaucoup!

Joris · Septembre 10, 2017, 4:33

Petites questions intermédiaires :

pourquoi MongoDB plutôt que Mysql (ou autre RDBMS) ?
pourquoi React ? as tu besoin de composants réactifs ?

(Je suis simplement poussé par la curiosité.)

Quoiqu’il en soit, si tu continues avec du NoSQL, voici un article qui peut t’aider
à appliquer des bonnes pratiques pour structurer tes données :
https://firebase.google.com/docs/database/web/structure-data

amirouche · Septembre 16, 2017, 5:03

C’est quoi ton xp en modélisation de schéma de base de donnée pour avoir plus de contexte.

Sinon, 16mo c’est normalement suffisant sauf si tu met toute ta base dans un document.

J’ai la flemme de lire ton schéma de du car je suis sur mobile. Mais la base de mongodb ce est de partir d’un schéma en 3e forme normal et ensuite de de normaliser en fonction de tes requêtes.

loganm · Septembre 22, 2017, 7:23

Pour bien schématiser, il faut bien connaître ton utilisation tant en lecture qu’en écriture. Et également avoir une bonne estimation de la charge (volume et fréquence) de tes cas d’utilisation.

Perso, sauf à avoir des données de charge, je partirai sur un schéma simple Offres, Candidat, Entreprise. A voir où stocker la relation entre l’offre et les candidats (soit dans l’un, soit dans l’autre). J’aurais tendance à favoriser dans “Candidat” car entre faire le suivi des candidats pour une offre, et le contraire, je pense que le second sera plus fréquent. On peut également envisager de stocker la relation dans les deux endroits.