Discussion :

[wakka369]

bonjour j'ai une table A, (par exemple des personnes), j'ai une table B (des biens), il existe une relation 1 to Many entre B et A (un bien peut appartenir a une seule personne à la fois, mais une personne peut posseder plusieurs biens)

sachant qu'un bien peut changer de propriétaire autant de fois que l'on veut,
Quels choix feriez vous pour modéliser la db pour garder l'historique de tous les anciens propriétaires d'un bien (et tant qu'on y est avec les périodes qui correspondent)

merci

[StringBuilder]

bah... le classique

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
create table appartenance
(
    id_personne int not null references personne(id),
    id_bien int not null references bien(id),
    debut date not null,
    fin date null,
    check (debut < fin or fin is null),
    primary key (id_personne, id_bien, debut),
    unique (id_personne, id_bien, fin)
)

Avec un petit trigger de validation pour les contraintes plus complexes :
- Chevauchement de dates
- Un même bien ne peut appartenir à deux personne en même temps (quoique ?)
- Éventuellement fermeture automatique de la période en cours à la veille du début de la nouvelle période

[wakka369]

eh bien un grand merci je débute donc ce n'était pas une évidence pour moi (d'ailleurs je n'ai pas encore vu les triggers)

[François DORIN]

Bonjour,

Et si les périodes sont contiguës et ne se chevauchent pas, il n'est même pas utile de sauvegarder la date de fin, puisque la date de fin d'une période correspond alors à la date de début de la suivante

[escartefigue]

bonjour,

Une alternative est de stocker une date de début, et une durée en nombre de jours

[SQLpro]

Bonjour,

Et si les périodes sont contiguës et ne se chevauchent pas, il n'est même pas utile de sauvegarder la date de fin, puisque la date de fin d'une période correspond alors à la date de début de la suivante

Pas forcément, un bien peut être en "sans maître" ou en déshérence, par exemple décès sans héritier...

A +

[François DORIN]

Pas forcément, un bien peut être en "sans maître" ou en déshérence, par exemple décès sans héritier...

Il y a quand même une hypothèse de départ que j'ai bien précisée : périodes contiguës Si un bien peut ne pas avoir de propriétaire, alors l'hypothèse de départ n'est pas vérifiée

[wakka369]

je comprend en théorie votre idée Mr Francois Dorin, mais on se complique la vie pour les requêtes SQL en faisant cela non ?

occuper le moins de place possibles l'emporte-t-il toujours sur des choix plus confortables ?

[François DORIN]

jmais on se complique la vie pour les requêtes SQL en faisant cela non ?

Et non. On complique "certaines" requête SQL, mais on en simplifie d'autres :

• cette utilisation "complique" les requêtes d'interrogation (et encore, avec une vue on retombe vite sur nos pieds) ;
• cette utilisation simplifie les requêtes de mise à jour,d'insertion et de suppression de données, puisqu'une seule ligne sera impactée à chaque fois.

Plus que de diminuer la taille de stockage des données, elle apporte une non redondance des informations et une cohérence des données qui est automatiquement garantie.

[StringBuilder]

En fait, une table historique avec une seule date, c'est exactement la même chose qu'un acte notarié : en effet, sur une cession, un acte de propriété ou autre document, il y a toujours la date d'effet, et jamais (sauf rares cas) la date de fin. En effet, même pour un bail, la durée est fixe, mais la reconduction étant tacite, en absence de tout autre acte, son effet dure aussi longtemps que nécessaire.

En revanche, pour la lecture c'est compliqué :
- A qui appartient un bien à un instant T ? => au lieu de faire un simple "ladate between debut and fin" on est obligé de faire une sous-requête* pour identifier la date la plus grande inférieure ou égale à la date recherchée
- Le bien B a appartenu à untel de quand à quand ? => idem, au lieu d'interroger une seule ligne, on va devoir se lancer à nouveau dans une sous-requête*

* sous-requête ou auto-jointure, fonction de fenêtrage... en tout cas, on passe d'un index seek à, au mieux, un simple range scan, au pire, à de multiples lectures

Sinon, pour en revenir à une autre suggestion, date + durée, personnellement, mise à part cas très particuliers, je n'en vois pas l'intérêt.
=> La durée, déjà, selon sa taille, on va vouloir utiliser différentes unités (heures, jours, mois, sciècles) sinon c'est illisible (27 ans, an jours, ça fait combien ? ah, oui, ça dépend à 100% de la date de départ... ou inversement, 12 jours, en année, ça fait combien ? ah, ça dépend de l'année...)

Donc dans ce cas, même si la durée est une donnée qui est réellement utilisée, il me semble préférable de passer par une ou plusieurs colonnes calculées, ou une vue, qui expose la durée entre les deux dates exprimées en différentes unités.

[StringBuilder]

Plus que de diminuer la taille de stockage des données, elle apporte une non redondance des informations et une cohérence des données qui est automatiquement garantie.

Pas forcément.

Si un bien n'est par exemple occupé que du 1er juin au 30 septembre tous les ans (maison de vacance par exemple) alors ta solution va nécessiter de créer des lignes bidon avec une personne "nulle" (ou "bidon", ce qui n'est guère mieux) qui va polluer la clé étrangère.
Ceci devient d'autant plus problématique si ton historique est porteur de propriétés (loyer, nombre d'occupants, relevé eau, caution versée, etc.)

[François DORIN]

Pas forcément.

Même remarque qu'à SQLPro. J'ai bien précisé des hypothèses pour qu'une telle approche puisse être efficace. En l'occurrence, les périodes doivent être contiguës. L'exemple que tu donnes est clairement un cas où cette hypothèse n'est pas vérifiée

[wakka369]

* sous-requête ou auto-jointure, fonction de fenêtrage... en tout cas, on passe d'un index seek à, au mieux, un simple range scan, au pire, à de multiples lectures

Appart la sous-requete, je ne connais aucun autre terme de cette phrase, mais me voila avec de quoi chercher, merci pour vos réponses à tous