Discussion :

[der§en]

Bonjour,

J'ai un petit problème d'algorithme à vous soumettre

Voilà, j'ai une table Nations et une table Villes, et je recherche là meilleure façon de les lier sachants qu'une ville au fil du temps à pu appartenir à telle nation et à autre moment à une autre nation.

Les nations ont dans leurs champs, leurs année de création et leur année de disparition.

Vous gériez cela comment vous ?

[tourlourou]

Bonsoir,

J'imagine que selon la proportion de villes qui n'ont appartenu qu'à une nation et le nombre de changements intervenus pour les autres, la solution idéale peut différer quelque peu !

Ceci reposant en outre sur un choix de structure plus volumineuse ou de traitement plus long si elle est moins adaptée...

[EDIT] peut-être verrais-je une structure Villes, Nations, Périodes, et une table liant l'appartenance d'une ville à une nation pendant une période. Et du coup, je lierais aussi les nations à une période de la table.

[der§en]

En fait, les villes ont au maximum changés 3 fois.

une idée de la meilleur approche pour le gérer simplement ?

[SergioMaster]

Bonjour,

J'ai un petit problème d'algorithme à vous soumettre

Algorithme ? j'aurais plutôt mis analyse ou structure de BDD

Les villes peuvent aussi changer de nom .... mais je ferais comme tourlourou 3 tables Villes/Nations/Périodes

Rapidement :
Nations (NIDUNIQUE BIGINT NOT NULL,NOM,PERIODEDEBUT NOT NULL,PERIODEFIN ....)
Villes (VIDUNIQUE BIGINT NOT NULL,NIDUNIQUE_ACTUELLE BIGINT NOT NULL,NOM, ......) relation NIDUINQUE NATIONS(NIDUNIQUE)
Periodes(PIDUNIQUE BIGINT NOT NULL,VIDUNIQUE BIGINT NOT NULL,PERIODEDEBUT NOT NULL) relation VIDUNIQUE VILLES(VIDUNIQUE)
je ne suis pas sûr que la période de fin soit utile pour les périodes si l'on considère qu'une ville a toujours une nation

A noter que pour chaque table la clé primaire est numérique et de préférence auto incrémentée

[der§en]

Merci pour vos réflexions, cela m'a éclairé sur une approche plus souple que celle que j'avais défini initialement

pour les clefs primaire, je procède généralement ainsi sauf cas spécifique !

[anapurna]

salut

3 tables
VILLES/NATION/APPARTIENT

VILLES{IDENT INT NOT NULL,NOM ....}
NATIONS{IDENT INT NOT NULL,NOM ....}
APPARTIENT{IDENT INT NOT NUL,VILID INT NOT NUL,NATID INT NOT NUL,DATEDEB DATETIME}

avec ces trois table tu as toutes les infos pour faire ce que tu veut
la date de début correspond a la date de rattachement à la nation et par construction la date de détachement à l'ancienne nation si il y a.
pas besoin de période les IDENT sont donc des identifiants auto incrémentée ce qui correspond a la clé primaire de chaque table

[der§en]

Intéressant, il faut que je regarde comment construire la requête pour extraire les villes et les nations pour une année donnée

[anapurna]

salut

Code sql :

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

1
2
3
4
select NATID, Max(ID)
FROM APPARTIENT
WHERE DATEDEB <= :DTPARAMS1  
Group BY NATID

[der§en]

Merci pour le coup de main.

Petite question: pourquoi max(Id) ?

pour info, il s'agit de construire une base de donnée communautaire pour un JDR (Polaris pour ceux que cela intéresse)

[SergioMaster]

Bonjour,

Petite question: pourquoi max(Id) ?

IDENT et non ID si l'on a la structure proposée. Mais c'est pour obtenir l'identification de la ligne les informations les plus "récentes" en fonction de la date donnée en paramètre
je rappelle que ID proposé est auto-incrémenté par le SGBD et que bien sûr il ne faut pas que "l'utilisateur" puisse modifier cette donnée sous peine de tout mettre en l'air .

Il suffit ensuite d'utiliser ce SQL en CTE (bien sûr cela dépend du SGBD ) pour obtenir la liste en clair, par exemple

Code sql :

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

1
2
3
4
5
6
7
8
9
10
WITH L AS (select NATID, Max(IDENT) ID
FROM APPARTIENT
WHERE DATEDEB <= :DTPARAMS1  
Group BY NATID)
 
SELECT N.NOM,V.NOM,A.DATEDB 
   FROM L JOIN  APPARTIENT A 
               JOIN NATIONS N ON N.IDENT=A.NATID
               JOIN VILLES V ON V.IDENT=A.VILID
ORDER BY N.NOM,V.NOM  -- Ordre alpha

[tourlourou]

pour info, il s'agit de construire une base de donnée communautaire pour un JDR (Polaris pour ceux que cela intéresse)

Super ! Du coup, je vois que Casus Belli reparaît... Je l'ai eu lu et regrette infiniment Jeux et Stratégies. J'en ai un carton pour meubler ma retraite !

[der§en]

Super ! Du coup, je vois que Casus Belli reparaît... Je l'ai eu lu et regrette infiniment Jeux et Stratégies. J'en ai un carton pour meubler ma retraite !

Veinard