Aide pour concevoir schema optimal

**vinch999** · 26/02/2014, 16h47

Bonjour voici ma demande :
SGBD : Postgres
Besoin : Des entités personnes ont une série de propriétés (environ 100) (Nationalité,catégorie,...) avec historique (start - end date)
Volumétrie : Millions de lignes . Environ 500k personnes avec chacun leur historique de propriétés.
Objectif : en un instant T , retrouver l'ensemble des propriétés d'une personne. Retrouver toutes les personnes d'une même nationalité,Etc.

En un instant t une personne possède une seule propriété par type de proriété, donc une nationalité , et une catégorie.
Imaginons que dans le temps cette personne puisse changer de nationalité, de catégorie, etc.
Chaque propriété peut être modifiée indépendament des autres.

Je pensais faire une table personne, une table nationalité, une table catégorie,etc + une table A reprenant : id_personne,id_nationalite,id_categorie,start_date,end_date.

Ce qui implique qu'à chaque changement pour une propriété, on ajoute une ligne dans la table A.
La table A aura donc un gros volume , avec 100 foreign keys.
On devrait indexer chacune des 100 colonnes afin de pouvoir retrouver rapidement , par exemple , toutes les personnes de nationalité française.
Cela engendre donc des indexes de volumes important.

Selon vous, un tel schema est-il viable, performant?
J'ai peur que le volume de la table A croisse trop rapidement.

Autre possibilité, des tables de jointures entre personne et chaque propriété avec id_personne,id_propriété,date_start,date_end
Ce qui impliquerait énormément de jointures.

Le but est bien sûr d'avoir de bonnes performances de requêtes.

Que suggereriez-vous comme schema?

Merci d'avance !

**Spartacusply** · 27/02/2014, 11h26

Hello !

La première solution n'est pas la bonne, elle implique une création de ligne à chaque changement de propriété, dupliquant ainsi celles qui n'ont pas bougé, ce qui d'un point de vue normalisation est incorrecte.

La deuxième n'est pas mauvaise mais mérite d'être complétée.

Ce que je peux te recommande dans ce cas là, c'est de bien différencier l'état actuel d'une personne (à cet instant même, récupère moi toutes les informations d'une personne) et l'historique d'une personne.
De manière générale, on accède beaucoup plus souvent à l'état actuel (le rendu doit donc être quasiment instantané), qu'à l'historique, qui lui peut être rendu un peu moins rapidement.

Ce que je veux te faire dire, c'est que l'état actuel d'une personne, doit se trouver dans la table de cette personne, ne pas en être désolidariser :

id_personne | nom | prenom | id_categorie| id nationalite
1 | Martin | Mélanie | 3 | 4

Ceci permet de retourner l'état actuel d'une personne.

Pour l'historisation d'une personne, tu peux avoir une table 'historique_personne', qui comprend quelque chose comme ça :

id_historique_personne | id_personne | colonne | value | date_start |date_end
1 | 1 | nom | Dupont | 2012-03-09 | 2012-05-09

Tu sais que Madame Martin s'appelait en fait auparavant Dupont (date_start peut-être vide si c'est depuis toujours, date_end est obligatoirement non NULL). Etant donné qu'on ne change pas de nom tous les jours, ça passe sans problème, et tu peux retrouver tes billes rapidement.