Contexte
Je compte me faire une petite appli de compta qui sera dans un premier temps dispo en ligne pour mon usage seul, je verrai par la suite. Ca remplacera l'excel avec lequel je fais ma gestion de compte. Là je m'intéresse au modèle

L'orientation que je compte donner à mon appli, c'est le prévisionnel : il existe une chiée d'appli de compta qui permettent de tracer le passé, moi j'en veux une qui permette aussi de simuler dans le futur. L'appli gérera donc des données réelles, et aussi des prévisions.

Pour des raisons de simplicité, je prend l'année comme unité d'encapsulation des comptes. On pourra créer des années dans le futur pour faire de la pure simulation si on veut.
Autre hypothèse : je pars du principe qu'on a un compte en banque, et que le but de l'application est de tracer/prévoir le solde du compte à un instant T

Le model tel que je le vois naivement :
L'appli maintient une liste d'années, contenant les années passées, l'année courante, et si on le souhaite, des années futures
Une années contient des mois
Chaque mois contient une liste de catégorie
Une catégorie contient des éléments (dépense ou recette mais ça a peu d'importance), et peut avoir un budget prévisionnel
Un élément contient donc un montant, a 2 statut : prévisionnel, ou réconciliée : prévisionnel c'est que l'entrée n'est pas apparue sur le relevé de compte, réconciliée c'est qu'elle apparait et qu'elle a impacté le solde du compte à la banque.

Voici les opérations de base :

• Manuellement :

- ajout/modif/etc d'une catégorie : on peut lui affecter un montant prévisionnel, qui sera ajouté/déduit du solde de compte. Par ex je peux dire : je compte 200€ de bouffe par mois, un salaire d'un Ratibus, 1/2 ratibus de prime en décembre,  etc...
- ajout/modif/etc d'une entrée : on choisit crédit/Débit, une catégorie, et un montant. Lors du rajout à la catégorie, on peut soit choisir d'impacter le montant de la catégorie. Par exemple je rajoute 50€ de carrefour. Ca peut vouloir dire :
   * que je compte dépenser 200€ de bouffe, dont 50€ de carrefour (auquel cas l'appli baisse la prévision de la cat "bouffe" pour que la somme reste à 200)
   * que je compte dépenser 250€ de bouffe (50€ à carrefour, et 200€ ailleurs)
- réconciliation :
   * automatique : le site de ma banque permet de télécharger mes comptes en CSV, QIF, etc...l'idée étant que je veux pouvoir avoir une réconciliation automatique
   * manuelle : je marque à la main les entrées réconciliées
le fait de réconcilier une entrée la sort du prévisionnel, et donc du calcul du solde réel.
Exemple : j'avais 100€ sur mon compte, et une dépense prévue de 10€. Mon solde réel calculé par l'appli est de 90€. Aujourd'hui j'ai reçu mon relevé, il indique 85€. Je réconcilie la dépense de 10€. Mon solde est toujours de 85€, la dépense ayant déjà affecté le solde à la banque. Elle apparait toujours pour des raisons de traçabilité, mais n'impacte plus mon solde.

• En automatique :

à toutes les fins de période (probablement le mois), je regarde si y'a des dépenses non réconciliées et je demande au user :
- soit de les réconcilier si c'est une erreur
- soit de provisionner la dépense dans la période en cours
- soit d'annuler l'entrée
idem pour les catégories avec le budget prévisionnel

De ça je veux pouvoir extraire les infos suivantes :

• le solde réel à un moment donné (fin du mois en cours, à n'importe quel jour donné, dans 6 mois, etc...)
• pouvoir dire à la fin de l'année : j'ai dépensé 2400€ en bouffe, et j'avais prévu 2500€, etc...

Mes questions
* ce truc est "simple" à modéliser, le problème ça va probablement être la performance ou la praticité d'utilisation : tel que je le conçois, ça va etre bcp de parcours de collection, sortir un objet, récupérer la collection qu'il y a dedans, remouliner, etc...
* aggréger un solde, c'est mouliner bcp d'info répartie à plein d'endroits
* les catégories me posent problème : y'a 2 dimensions : une dimension mensuelle / annuelle, etc...et une dimension par catégorie. Je pensais ajouter l'objet qui représente la catégorie pour un mois donné à la fois à la liste des catégories du mois concerné, mais aussi à un objet listant toute les instances de la catégorie concernée. Par exemple, rajouter "bouffe du mois d'avril" à la fois au mois d'avril, et aussi à la catégorie "bouffe"...
* je sais pas si j'ai une pertinence à avoir un découpage objet année / mois...une grosse liste avec les dates me permettrait de faire le même découpage, c'est peut etre une optimisation inutile (je pense garder l'année quand même parce que ça semble une bonne unité d'analyse, et que c'est logique au niveau archivage, etc...)
* je compte fournir des vues semaine, mois, trimestre, etc...je vais donc sans cesse afficher des subsets de ma grosse liste d'entrées...c'est quoi le plus élégant ici ?
   - balancer la grosse liste, et filtrer la vue uniquement
   - créer une petite liste et y copier uniquement les références des objets qu'on veut afficher
* je compte utiliser Joda time, ça me semble plus prudent
* vous voyez des choses auxquelles faire gaffe ?

Pour tes pb de perfs & d'implé anné/mois/etc... à ta place j'aurais envie d'utiliser un petit moteur de sgbd embedded (sqlite, hsqldb, ...) et lui déléguer les menu détails d'indexation/optimisation de tes parcours, l'ajout de nouveau rapports & co. en sera d'autant plus simple.

c'est une bonne idée  
c'est clair que je vais y gagner beaucoup pour trouver les subsets de périodes (sortir toutes les dates tombant en avril 2009 c'est trivial).
 
après je sais pas si ça va m'aider au niveau des calculs...quand je vais sortir les infos du SGBD, je vais etre obligé de les reparser pour faire mes calculs...sur une liste plus petite certes, mais je suis pas sur d'y gagner tant que ça...l'itération sur une list étant pas hyper gourmand
 
en gros s'opposent un modèle où je charge le set d'info complet en mémoire et je me balade dedans, d'un autre où l'info reste en base, et je sors que ce dont j'ai besoin...
 
c'est vrai que je me suis pas encore posé la question de la persistence, je pensais persister le bousin dans un fichier xml au départ, ou en tout cas le permettre rapidement, histoire d'avoir une porte de sortie du SGBD...
si par la suite je le release comme appli publique, le fait de pouvoir importer/Exporter vers des formats genre Money/QIF/OFX serait un gros plus...

Relatif au problème de conception et de formatage des données, parts dès le départ sur une conception indépendante d'une technologie. Te forcer à utitliser un moteur de SGBD dès le début pourrait t'aider à créer un wrapper pour l'accès aux données.
Ton application pourra ainsi facilement dans le futur changer de technologie pour l'accès aux données (embedded SQL, serveur SQL, XML, Access, ...). La performance pour une application de ce genre n'est pas critique.
 
Essaye d'avoir une normalisation de ton modèle de donnée, c'est plus lourd à écrire au départ, mais ça sera beaucoup plus facile pour ajouter des features dont tu n'as pas encore pensée et qui se veront peut-etre limité par ta conception actuelle.
 
Pour une potentielle future distribution de ton logiciel, parts également sur une API pour la gestion du calendrier qui par exemple te proposera différent modèle de calendrier (et leur subtilité) et ne limitera pas seulement ton application au calendrier grégorien.

justement, Joda time sert à ça ...c'est une API Java pour la gestion des dates, bien mieux foutue que l'API de base Java, et qui gère par défaut 8 systèmes de calendriers et fournit la tuyauterie pour faire la localization

pour ton premier commentaire je comptais bien faire comme ça...je pars sur du MVC, et je sais que dans M il faut décorréler la logique de la persistance des données...dans le meme registre, ça restera pas forcément toujours une appli web, donc je veux encapsuler le modèle au maximum

up...D'autres avis ? le petit nraynal est demandé à l'accueil