Pour mon taf je gère des licences. Quant on met à jour une licence, par exemple 123456, l'éditeur nous renvoit une nouvelle licence, par exemple 456789. La licence 123456 est morte et remplacée par la nouvelle licence 456789.
 
Une licence neuve n'aura pas d'ancetre, mais une licence un peu ancienne et déjà mise à jour plusieurs fois pourra avoir un nombre indéterminé d'ancetres.
 
Par ex je peux avoir :  
 
123456 --> 456789
987654 (licence neuve)
654321 (licence neuve)
123789 --> 789123 --> 456123
 
comment modéliser ça ?
L'immense majorité du temps, je ne travaille que sur les licences "à jour" (dans mon exemple les non barrées) donc par défaut je veux que ma BDD soit orientée gestion des licences courantes
 
j'avais pensé faire un champ "successeur" qui contient la FK de la licence qui la remplace...si le champ est vide c'est une licence courante
ma question c'est si je fais ça comment requeter sur une licence ancienne pour connaitre le numéro de licence le plus à jour ?
par ex si j'ai ça 123789 --> 789123 --> 456123 comment en requetant sur 123789 je peux obtenir 456123 ?
 
une autre solution peut etre plus simple est lorsqu'une licence est entrée dans ma base, créer une table de validité à coté ayant les champs #licence d'origine, #nouveau num, date de MAJ
et là je requete comme suit : je cherche dans cette table un vieux numéro de licence, je trouve quel était le numéro de licence d'origine (le 1er de la chaine), et ensuite je cherche dans cette table quel est le numéro de licence le plus à jour lié au numéro de licence d'origine (celui qui n'aura pas de date de MAJ dans mon exemple)
 
vous feriez comment ?
 
 

pour ta première solution, en oracle par exemple, il existe "CONNECT BY PRIOR" qui te permet de retrouver le plus courant à partir d'un ancètre.  
 
sinon suffit d'avoir une table en parallele dans lequel tu mettrais un numéro de séquence relier entre eux.

j'utiliserais probablement access (oui, je sais )

oulalala tu es mal la.

oh je sais...
 
en fait c pour moi cet outil, et j'ai bien sur 0 budget pour le faire...je suis gestionnaire d'un outil qui a un modèle de licence à coucher dehors, sachant qu'en plus on a changé de modèley'a 2 ans, et qu'on doit lancer un inventaire majeure pour rappatrier tt les anciennes licences dans le nouveau modèle...et avec Excel c'est plus gérable...
 
mais en fait si ça devient trop tendu, je sens que je vais me mettre un petit postgreSQL avec PGAdminIII ou un truc du style...tant pis je me ferais des vue, ce sera pas user friendly mais bon...

ton numéro de licence, c'est un identifiant pour d'autres données ou non ?
c'est une donnée membre d'une autre info ou non ?
 
y'a quelques solutions simplissimes qui me viennent à l'esprit, mais elles dépendent de tes réponses
 
en tout cas de base, vu ton besoin, je pense que la notion de hiérachie est mauvaise, il faut partir sur une notion d'historisation plutôt.
 
poste la tête de tes tables pour voir.

elles sont pas faites mes tables, je réfléchis...pour l'instant la donnée existe dans plein de fichiers excel merdiques
 
en fait les données sont un peu comme ça :  
 
y'a des contrats de maintenance. A l'époque nos clients avaient chacun leur propre contrat, et maintenant on a un contrat unique pour tout le groupe. A noter que les contrats sont valables tant qu'on paye la maintenance. On a des licences qui ne sont plus rattachées à un contrat.
Sous un contrat, tu as :  
- des licences logicielles
- des licences matérielles, qui sont plus ou moins liées aux licences logicielles : en théorie un soft = une licence matériel...dans la pratique on a du vieux matos qui contient des bits de licence, qui ont toujours une valeur...donc on va les recencer.
- des licences matérielles optionelles : sur une carte tu peux donc avoir le bit de licence pour le soft, et des bits pour les options.
 
quant tu mets à jour une licence logicielle, son numéro de licence change. Dans le cas où c'est une vieille licence qu'un client possédait avec son propre contrat, le process de la mettre à la jour la rattache au contrat cadre de maintenance.
 
C'est tout le bordel de ce modèle de données : les liens sont faibles, et peuvent casser. On peut pas utiliser le numéro de contrat comme clé de rattachement parce qu'il peut évoluer dans le temps. Le numéro de licence logiciel change aussi dans le temps, d'où mon idée d'utiliser le premier comme clé de la petite suite formée par tous les numéros successifs.
 
Le seul truc invariant est le numéro de série du matériel, mais y'a pas de lien forts entre le matériel et le numéro de licence logiciel. Si t'as le licence bit de la v5, tu peux l'utiliser avec tt les v5 du monde, quel que soit leur numéro de série logiciel...
 
la seule chose dont j'ai besoin, c'est de pouvoir suivre l'historique des numéros de licence

T'ain
 
T'as pas trop mal à la tête ?
 
Bon, ben le plus simple, je pense :
- Tu gardes le numéro licence originale
- Tu fais une table de correspondance "première licence - nouvelle licence"
 
Et comme ça t'as qu'à faire un inner join entre les deux tables sur le numéro de licence originale, et filtre sur la "nouvelle licence" (sâchant que tu crées toujours une ligne, même pour le premier numéro)
 
Ainsi tu récupère aisément le dernier numéro de licence, et tu peux rechercher par n'importe quel vieux numéro.
 
Si par contre ton numéro de licence est porteur d'informations (type de licence, version du logiciel, logiciel, etc.) et que tu peux faire évoluer la licence vers une nouvelle version par exemple, ça commence à devenir plus chaud. A mon avis il faut déporter ces infos dans cette table d'historique.

PS : Pkoi ne pas utiliser SQL Server Express ? Rien ne t'empêche de faire un front end avec Access...
 
Parceque là, vu le bordel, sans view et procédures stockées, colonnes calculées, tu vas en chier des bulles...

oui c'est une possibilité

sinon les inner join je maitrise pas bien, je regarderai ce que ça fait
et oui, la licence logicielle est porteuse d'info : version du soft, modules activés (les fameux modules pour lequels il existe les licences matérielle optionelle)

et ce truc est une horreur à gérer, le pb c'est que ma boite s'est lancée là dedans sans trop checker, et maintenant c'est à moi de rendre le machin viable...à un moment je pense que ça va devenir ingérable, on va devoir simplifier des trucs...

ben les inner join, c'est un peu les joins de base hein

Bah tu sais, à un moment, c'est à l'analyste de dire :
 

 
Ton truc, ça me rappelle le bignou d'Econocom.
Le truc bordélique à souhait, et... en plus, inutile.
Genre y'avait une équipe de 10 personnes (un service tout entier en fait) pour faire tourner la tambouille, sâchant que ça ne servait strictement à rien !
 
Le machin édifiant quoi... A la base, une feuille Excel avec 100 fois moins d'infos mise à jour une fois par mois par une secrétaire aurait été tout aussi efficace, mais non, "il a fallu faire une application pour savoir quel était le numéro de série des piles qu'il y avait dans la souris livrée avec l'ordinateur doté d'une carte graphique qui a 256 Mo de mémoire et deux connecteurs DVI et qui est paramétrée en 80 colonnes monochrome sur un écran 12" à l'entrée de la machine à café..." (le tout n'étant pas du texte, mais bien des propriétés de matériels liés entre eux et tout ça)
 
=> C'est pas plus simple de dire que la société Bidule a un PC en leasing dont le matos est "blabla champ texte" et dont le loyer est de 10 € par mois ?
 
Bah nan... Il a fallu faire une usine à gaz...
Mais là où c'est le plus fun, c'est que c'est les clients qui achètent le matos, alors il fallait ressaisir toutes les factures que les clients envoyaient, et comparer avec le catalogue des fourniseurs pour retrouver le détail des machines
Alors qu'un bête "facture # / ligne #" aurait été tellement plus simple comme description du matériel (puisqu'au final, le seul truc utile, c'est de calculer le montant du loyer du matériel, à partir de sa valeur d'achat et de son age...)

le pb c'est que ces règles métier c'est notre fournisseur qui nous les impose, moi j'y peux rien...

et quand je dois faire une MAJ client, je dois retrouver quel contrat correspond à quel matos...

et enfin, je dois facturer mes clients, donc je dois savoir combien de licences ils possèdent...

sinon c sur je me ferais pas chier, mais Excel a montré ses limites

ceci dit, j'hésite à ne modéliser que ce qui rentre dans notre contrat cadre, pour lequel les règles sont plus contraintes (tt les licences sont rattachées à un seul contrat, et je sais quel matos y est rattaché aussi)

Je sais pas trop quoi répondre.
Si tu fais ça, réfléchis quand même à un moyen pour faire évoluer le truc pour gérer un minimum les moutons à 5 pattes, parceque tu risques de devoir tout refaire sinon. Mais clairement, vu le bordel dans les règles, je dirais qu'à force de tenter de faire rentrer des ronds dans des trous carrés, tu vas jamais réussi à faire un truc qui marche correctement dans le cas général...

ouf, je pensais être le seul, mais non, on est bien d'accord : avec ces règles métier, c'est imbitable...

ben tu peux essayer de poster ton dictionnaire des données et tes règles. si j'ai beaucoup de temps à rien faire (ou quelqu'un d'autre) on pourra y jeter un oeil, mais vu ce que j'ai lu du début...

la semaine prochaine la personne qui gérait ça avant vient pour finir de me passer les billes.
 
Je verrai pour formaliser qqc...