Parent-child assets : quand une docking station appartient au laptop
Le modèle relationnel, les trois types de relation et le cycle-guard — pour le jour où une docking station est partie avec le laptop et où vous ne voulez pas en perdre la trace.
Une docking station est partie avec le laptop. Deux SFP transceivers sont arrivés avec le switch. Huit modules de RAM sont sortis d’un même serveur. Aucun de ces éléments n’est un asset indépendant — ils appartiennent à un parent, et les traiter comme des rows autonomes fait perdre la relation dès l’instant où quelqu’un prend le parent sans se souvenir des children.
La relation
Chaque asset peut pointer vers un parent asset. La relation est asset-to-asset (pas asset-to-product ni asset-to-pallet) et elle porte un type : harvested from pour un composant sorti d’un device, mounted in pour une pièce montée à l’intérieur, et bundled with pour un accessoire qui voyage à côté. Un laptop avec un dock a le laptop comme parent et le dock comme child, bundled with. Un switch avec deux SFPs a le switch comme parent et chaque SFP comme child, mounted in. Le parent et le type de relation se fixent ensemble ou pas du tout — la base de données refuse un parent sans type et un type sans parent.
Le cycle-guard
La plateforme refuse de créer une relation parent-child qui formerait une boucle. Quand vous choisissez un parent, le picker écarte déjà l’asset lui-même et tout ce qui se trouve en dessous ; le serveur fait ensuite le contrôle qui fait foi en remontant la chaîne du parent proposé et en rejetant le choix si le child y apparaît quelque part (A→B, B→C, C→A est rejeté). Si une chaîne existante est déjà corrompue, la plateforme refuse de construire dessus plutôt que de faire comme si tout allait bien. Il n’y a pas de limite de profondeur — une chaîne est un arbre, ou elle ne l’est pas.
Ce que montre la page de détail
Depuis un child, vous voyez l’asset tag de son parent et pouvez y sauter. Depuis un parent, vous voyez ses children et leurs statuts. Chaque changement de relation écrit une row d’Activity avec l’ancien et le nouveau parent, donc « quand ce SSD a-t-il cessé d’appartenir à ce serveur » a une réponse horodatée.
Pourquoi le modéliser explicitement
Parce que l’alternative consiste à encoder la relation dans un champ notes, et un champ notes ne survit ni à un tri, ni à un filtre, ni à un export. Modéliser la relation explicitement, c’est la faire survivre — et le dock voyage avec le laptop comme asset suivi à part entière, au lieu de se cacher dans une description. Un arbre est une structure de données. Une note est un espoir.