Une petite question de design à vous soumettre :
 
j'ai trois Classe d'objets dont les instances ont un état, qui évolue fatalement avec le temps. L'état est stocké en base, comme tout le reste.
 
Il me semble qu'il existe une méthode (que j'ai vu employée sur une des premières appli à laquelle j'avais légèrement participé il y a bien longtemps), une méthode donc qui fait ajouter un champ avec la date du changement d'état.
 
Donc pour récupérer l'instance courante de mon objet, je prends qui à la date de changement d'état la plus grande.
Et si je veux consulter l'historique de mon instance, j'y ai accès avec cette même date.
 
Est-ce que ce design sent le mouflon, ou est-ce que c'est pas trop mal ?    
 
question subsidiaire : Maintenant, je me demande comment inscrire ça dans une appli J2EE qui utilise Hibernate pour la persistance  des objets.
Je me verrai bien utiliser l'élément judicieusement nommé version, mais je suis douteux : la doc parle de son utilité dans des transactions longues, qui me concernent guère dans ce cas. En même temps, j'ai comme l'impression que le salut est par là.
 
j'ai bon ?
 
edit: changement de cat
edit²: re-changement de cat. Finalement je me dis que ce design est bon, reste à configurer Hibernate avec discernement.

up suite au changement de cat

bon, je me rends bien compte que ça passionne pas les foules, mais j'insiste quand même.
 
comme j'ai mis plus haut, je suis d'accord avec moi-même, et je vais partir sur cette solution. Je continue le post, même si ça intéresse personne, ça me permet de poser mes idées, et des fois ça en intéressera d'autres... un jour. ou pas. Bref.
 
Malheureusement pour moi, les doutes que j'avais sur le versionning hibernate se vérifie. Ca marche pas trop comme je m'y attendais. Le versionning sert surtout à maitriser la mise à jour de la base par plusieurs contrôleurs (c'est pas le mal ça normalement ??).
 
Ce que je voudrais, c'est que la date soit mis à jour quand je modifie mon objet. En fait pas tout mon objet. Principalement un attribut nommé Etat, qui contient... l'état de l'objet.
 
Donc je me retrouverais avec un clef primaire qui contiendrait l'id de l'objet et la date de mise à jour. Les liens entre tables sur clef étrangères pourraient rester sur l'id, pas de soucis. Par contre, pour récupérer la dernière version d'un objet, ça m'oblige à requêter sur une partie de la clef (max dt_maj), et je crois qu'Hibernate apprécie moyen, mais je vais tenter le coup.
 
Je vais tester quand même, pour être sûr...
 
A bientôt, pour de nouvelles aventures où je parle tout seul.

hum... donc en fait, je tâtonne grave.
 
Une clef étrangère sur un partie de la clef primaire de la table pointée, c'est pas possible (en même temps ça se tient).
 
Je pourrais ajouter un nouvel identifiant, technique, à mon objet. Mais ça imposerait de mettre à jour tous les liens vers l'ancienne version de l'objet pour utiliser la nouvelle version... ça me semble foireux. En tout cas avec Hibernate.

Oups j'avais oublié de répondre à ce topic.
Je ne sais pas si ça correspondra à tes attentes :
http://martinfowler.com/ap2/timeNarrative.html

merci, je vais éplucher ça, ça semble coller pas mal.

en fait chui un peu con, si je sors etat et date_etat dans une struture table/externe, je devrais pouvoir faire ça trop plus de soucis...
 
m'enfin j'y réfléchirais plus demain.

ok, donc pour moi, ce sera un temportal object
 
merci charly pour ce site d'une clarté à toute épreuve.