Index: topia/doc/PersistenceImplantationJDBC.rst
diff -u /dev/null topia/doc/PersistenceImplantationJDBC.rst:1.1
--- /dev/null	Thu Jul 21 16:52:15 2005
+++ topia/doc/PersistenceImplantationJDBC.rst	Thu Jul 21 16:52:10 2005
@@ -0,0 +1,83 @@
+==================================
+Implantation d'un storage sur JDBC
+==================================
+
+:Authors: Benjamin POUSSIN <poussin@codelutin.com>
+:Version: $Revision: 1.1 $
+:Date: $Date: 2005/07/21 16:52:10 $
+
+L'idée est d'implanter un storage sur JDBC en utilisant le JDBC le plus simple
+possible pour qu'il n'y ait qu'un implantation quelque soit la base de donnée.
+
+Il sera possible d'utiliser dans le futur des libriaries tel que ldbc, crossdb,
+commons-sql, .... Mais seulement si cela n'est pas au détriment des
+performances.
+
+Schéma de la base
+=================
+
+Le choix est fait de n'avoir que deux tables, une pour les données de gestion et
+une pour les datas, cela permet d'avoir ensuite du code simple. Une autre strategie qui pourrait etre mise en place pour des raisons de performance serait d'avoir deux tables par type d'entité.
+
+
+La table de gestion
+-------------------
+
+- id: identifiant de l'objet
+- date: date de l'objet
+- class: classe de l'objet pourrait etre retrouvé par l'id, mais moins
+  performant
+- isNew: vrai si l'objet est un nouvel objet
+- isDeleted: vrai si l'objet est supprimé
+- schemaVersion: version de schema de l'entite stockée
+
+La cle primaire est id+date
+
+La table de data
+----------------
+
+- id: identifiant de l'objet auquel appartient le champs
+- date: date de l'objet auquel appartient le champs
+- field: nom du champs
+- value: valeur du champs
+
+La cle primaire est id+date+field.
+
+le choix d'avoir un champ par enregistrement permet de simplifier tres
+grandement le changement de schema des entites et permet d'avoir une seul table
+pour toutes les entites. L'inconveniant est qu'il faut plusieurs operations pour
+ajouter un nouvel objet.
+
+Les requêtes utiles
+===================
+
+date est toujours un id de transaction donc il est negatif
+
+Recherche des attributs d'un objet: id, date
+
+  SELECT field, value FROM data WHERE id=? AND date=?;
+
+Recherche de la derniere version d'un objet: id, date
+
+  SELECT id, date FROM management WHERE id='b' AND ((date > 0 and date<=1500) or date=-1500) order by abs(date) desc LIMIT 1;
+
+ou
+
+  SELECT id, date FROM management WHERE id=? AND date=?;
+  si pas de resultat faire la suivante
+  SELECT id, MAX(date) FROM management WHERE id=? AND date > 0 AND date<=-? GROUP BY id;
+
+Recherche si un objet exist: id, date
+
+  la meme requete que pour la recherche d'un objet mais avec un select different
+  SELECT isDeleted FROM management WHERE id='b' AND ((date > 0 and date<=1500) or date=-1500) order by abs(date) desc LIMIT 1;
+
+Recherche de tous les id valides: date
+
+  SELECT DISTINCT(id) FROM management WHERE (date=? OR (date>0 AND date<=-?)) AND id NOT IN (SELECT id FROM management WHERE (date=? OR (date>0 AND date<=-?)) AND isDeleted=true);
+
+Recherche des N derniere version d'un objet tri par date: id, date, N
+
+  SELECT id, date FROM management WHERE id='b' AND ((date > 0 and date<=1500) or date=-1500) order by abs(date) desc LIMIT N;
+
+