[noalyss-generale] Conseils pour structurer le code

[Discussion à propos de NOALYSS , développement , support . . .]

  Bonjour,

  Je continue à travailler en local pour arriver à produire
les documents comptables d'une copropriété. J'aurais besoin
de quelques conseils sur des questions de structuration afin
de partir tout de suite dans une direction acceptable pour une
intégration officielle.
  Autrement dit, mes questions ne sont pas "comment écrire le
code ?" mais plutôt "comment structurer la base de donnée"
sachant que je vois plusieurs possibilités et que je ne sais
pas laquelle choisir.

* lien PA <-> clé de copro
==========================
  J'ai besoin de lier chaque clé de copro avec un poste
analytique. Pour l'instant, j'ai ajouté une colonne dans
coprop.clef_repartition :
ALTER TABLE coprop.clef_repartition
        ADD po_id bigint;
ALTER TABLE coprop.clef_repartition
        ADD CONSTRAINT clef_repartition_po_id_fkey FOREIGN KEY (po_id)
                REFERENCES poste_analytique (po_id) MATCH SIMPLE
                ON UPDATE CASCADE ON DELETE SET NULL;
COMMENT ON COLUMN coprop.clef_repartition.po_id IS 'Poste analytique';

Est-ce ok, ou faut-il mieux une autre table (cle_id, po_id) séparée ?

* lien copropriétaire <-> PA
============================
  J'ai besoin de lier chaque copropriétaire avec un poste
analytique. Pour l'instant, j'ai ajouté un attribut dans la
fiche 'copropriétaire'.
Avantage : c'est standard
Inconvénient : le poste n'est pas supprimé dans la fiche quand il
  est détruit dans les plans comptables analytiques

  Autre possibilité : une table (fiche_id, po_id)

* affectation budget
====================
  Avant, chaque ligne de budget était associée à une clé de copro.
J'ai besoin qu'on puisse aussi associer une ligne de budget à un
copropriétaire particulier.

Mon implémentation temporaire : deux colonnes dans coprop.budget_detail
+ une colonne pour choisir le type d'affectation (clé ou copro)
+ une colonne pour choisir le copropriétaire
Ce qui donne :
CREATE TYPE coprop_or_key AS ENUM ('cle', 'copro');
ALTER TABLE coprop.budget_detail
        ADD f_copro_id bigint;
ALTER TABLE coprop.budget_detail
        ADD CONSTRAINT budget_detail_f_copro_id_fkey FOREIGN KEY (f_copro_id)
                REFERENCES fiche (f_id) MATCH SIMPLE
                ON UPDATE CASCADE ON DELETE CASCADE;
COMMENT ON COLUMN coprop.budget_detail.f_copro_id IS 'Fk vers fiche 
copropriétaire';
ALTER TABLE coprop.budget_detail
        ADD bt_rtype coprop_or_key NOT NULL DEFAULT 'cle';
COMMENT ON COLUMN coprop.budget_detail.bt_rtype IS 'Imputation par clé ou par 
copropriétaire';

Autre possibilité :
ne pas toucher à coprop.budget_detail, et créer une clé par copropriétaire
avec juste ses propres lots dedans

Autre possibilité : faire une ou plusieurs tables supplémentaires pour
compléter coprop.budget_detail

...


  Je veux bien un avis ou des propositions de structuration pour ces
trois problèmes.


  Enfin, j'ai une question : à quoi sert la table appel_fond_detail ?
Ou, mieux formulé, pourquoi existe-t-elle alors qu'elle contient des
données temporaires qui sont écrites et lues pendant la même exécution
de la page php appel_fond.inc.php (avec le paramètre calc).
Le code (simplifié) est :
               switch ($aft)
                {
                        case 1:
                                $appel_fond = new Coprop_Appel_Fond();
                                $appel_fond->compute_budget($_GET);
                                break;
                        case 2:
                                $appel_fond = new Coprop_Appel_Fond();
                                $appel_fond->compute_amount($_GET);
                                break;
                }

                $appel_fond->display_ledger();

Pourquoi ces données ne sont pas justes stockées en mémoire dans la classe
Coprop_Appel_Fond entre "compute_budget/amount" et display_ledger ?
Je n'ai pas l'impression que ces données sont réutilisées ailleurs...

  Voilà, je m'arrête là (pour l'instant) avec mes questions ;-)

  Cordialement,
    Vincent