Suite du projet

[Marc SCHAEFER]

On Thu, 13 Dec 2001, Alexandre Galletet wrote:

> > Ma proposition: dans la table ecriture, rajouter un champ "references"
> > qui pointe vers une autre table (a definir plus tard), qui peut
> > continuer le no de la piece et eventuellement une URL (qu'elle soit
> > en http:// ou en file://), ou tout autre moyen de se referer a une
> > piece. Ca ne surcharge pas trop la table des ecritures, et seules les
> > ecritures qui ont besoin des references creent un enregistreement dans
> > la table adequate. Opinion ?

> Au lieu de rajouter un champ "référence" ne peut-on pas se baser sur un
> champ déja existant p.ex. id ? (Marc?)

Effectivement, il y a deux façons de le faire:

   - si on suppose que chaque écriture a au plus une URL p.ex., un
     simple REFERENCES de ecriture à truc suffit.     

   - une autre façon de voir le problème est à l'envers: autrement dit
     de référencer DEPUIS truc jusqu'à écriture.

     Cela a comme conséquences:

        - sauf ajout d'une relation lien on ne peut pas référencer plus
          d'une écriture avec truc.

        - extensibilité accrue: on peut créer N tables truc_url,
          truc_whatever (encore que dans un URL/URI on peut stocker
          finalement tout)

        - multiplicité possible et facile

        - la destruction d'une écriture est maintenant sujette à
          réflexion: est-ce que cela doit également détruire
          le ou les objets référencés à l'envers ?

Il y a même une troisième qui est la plus complexe, et dont la deuxième
est un cas particulier, mais la moins limitée:

   CREATE TABLE truc(id SERIAL NOT NULL, uri TEXT);
   CREATE TABLE truc_de_ecriture(ecriture_id REFERENCES ecriture NOT NULL,
                                 truc_id REFERENCES truc NOT NULL,
                                 _contraintes_);

   avec _contraintes_ dépendant de la cardinalité de cette relation.