Specs

[Frederic Schutz]

Le Wed, 4 Jul 2001 09:13:50 +0200, tu as ecrit :

>>   - suivant les db, quelles sont les possibilités de faire des "locks"
>>     sur certaines données pour empêcher qu'elles soient affichées/changées
>>     pendant qu'un utilisateur les modifie ?
>
>Facile sous PostgreSQL (cf. "SELECT FOR UPDATE").

Bien.

>>   - Au moment d'entrer une nouvelle écriture, le logiciel devra connaître
>>     le numéro de la dernière écriture pour attribuer le numéro suivant.
>>     Il est impossible d'utiliser les fonctionnalités auto_increment des db,
>>     car il y a plusieurs numérotations différentes (suivant les sociétés)
>>     dans la table.
[...]
>Troisième possibilité:
>
>- - sous PostgreSQL, définir un trigger "auto incrément" qui fait le
>incrementation suivant les règles de numérotation souhaité.  Facile.

Effectivement. J'ai été voir la doc de PostgreSQL, ces histoires de trigger
ont l'air très intéressantes (il faut que je me mette plus sérieusement aux
bases de données à l'occasion).

>Petit question: qu'est-ce qu'on fait avec les écritures qui étaient
>démarrés mais annulés avant complétion?  Est-ce qu'ils devrait avoir un
>numéro, ou est-ce qu'on assigne un numéro SEULEMENT pour les écritures
>complété?

Seulement pour les écritures complétées à mon avis. Les écritures
incomplètes ne doivent pas figurer dans la comptabilité, et il ne faut pas
qu'il y ait des trous dans la numérotation des écritures valables.

>>   La même question se pose au moment où on veut afficher le solde d'un
>>   compte: faut-il parcourir toutes les écritures pour trouver celles qui
>>   font partie de ce compte, ou faut-il tenir à jour (rigoureusement !) le
>>   solde du compte chaque fois qu'une écriture y est ajouté ou enlevé ?
>
>Facile d'être rigoureuse avec des triggers qui font les sommes au moment
>de chaque UPDATE et mettent les résultats dans un table sommaire.

De nouveau, ça a l'air d'être une bonne solution.

Voila des questions vite répondues :-) Merci Erik !

Fred.