pour LDAP et XML ce sont des arbres. un arbre est un graphe non orienté sans cycle.
pour les solutions, je parlais en libre et à ma connaissance. en non libre, j'en connais deux ( tamino et une autre dont j'ai oublié le nom ).
je te concede tout à fait que l'estimation à la dizaine etait trop faible. mais meme aux dizaines cela reste faible. je m'explique.
en guise de preambule, la compta d'un point de vu legale, est l'ajournement de TOUTES les operations numeraires d'une entreprise. dans un modele economique où tout à une valeur numéraire ( d'échange, compensatoire ), la compta devient donc l'ajournement de TOUTES les operations d'une entreprise.
nous avons la compta au bilan, qui donne un etat des mouvements numeraire d'une structure à un instant donné. cette compta permet de construire un bilan de la société. mais le bilan ne donne pas d'autres informations qu'une photo d'un batiment : selon l'angle, la lumiere, la position, on peut ne pas voir la meme chose.
est arrivé la compta analytique au moment de l'industrialisation, pour pouvoir faire des bilans d'unité comptable. l'unité est un centre d'abstraction permetant de voir simplement des transactions sur les autres centres. pareil, selon la maniere de la construire, des pertes deviennent profit et la machine à café 90% de la marge brut :)
il est important de noter que tout mouvement, operation, necessite au moins un emetteur et un recepteur qui se nomment en comptabilite un crediteur et un debiteur. conclusion, une operation peut representer au moins une action de debit et une de credit.
un autre point à comprendre dans la comptabilité : le plan.
le plan ou plan comptable, est l'organisation arborescence des flux numéraires de l'entreprise. la racine du plan est l'agragateur ultime des flux. en gros, la difference, entre deux bilans, permet de donner une mesure des mouvements effectués. attention, cette difference ne mesure que le volume total des flux et non le nombre de flux et ce qu'ils represente.
la racine ne signifie donc rien. il faut donc preciser les flux par une specialisation avec des branches. qui faut continuer de specialiser ... àl'infini.
la compta n'admet qu'une operation mathematique : l'addition de nombres positif ou nul. donc chaque noeud du plan comptable contient deux valeurs : un credit et un debit.
aujourd'hui, quand une entreprise facture en jour-homme, elle peut crediter et debiter des comptes idoines pour avoir un suivi financier du projet assez precis. je tiens à preciser que la granularité temporelle n'est pas un facteur limitant, tu fais ce que tu veux et tu adapte comme tu veux.
si tu veux, une implementation au dessus d'un DNS ou d'un LDAP est possible, mais aujourd'hui, compte tenu des specificités de ces protocoles, la compta n'est pas trop adapté, car elle plus en ecriture qu'en lecture.
et c'est là, qu'apparait le probleme des SGBD et autres FS : aujourd'hui, tout le monde sait faire des lectures simultanées en garantissant la coherence, mais les ecritures simultannées rapide garantissant la coherence, tiennent de la gageure.
je te donne un exemple :
la constitution d'une SARL d'un point de vu comptable :
voici les comptes ( chaque chiffre represente une navigation dans le plan comptable , comme un XPath )
debit | credit
--------------------------------- promesse d'apports
45611
45615
101
--------------------------------- constitution du fond avec les apports
2* (immobilisation)
3* (stock)
45611
----------------------------------- sequestre des fonds
467
45615
----------------------------------- deblocage des fonds
512
467
------------------------------------ frais de constitution
2011
447
donc, il faut au moins 12 mouvements sur 9 feuilles comptables, qui réagrégé, representent au moins 41 mouvements sur le plan. comme tu as pu le constaté, les operations effectuées peuvent etre agrégé en une super operation : comme pour coder, nous avons un graphe d'appel des primitives comptables pour pouvoir faire des "scripts" comptables et operer rapidement.
comme c'est un cas facile et assez trivial, je te laisse imaginer pour la gestion d'une SSII, la comptabilisation d'une prestation au forfait jourhomme en cas de depassement de delai avec compensation financiere ventilé sur plusieurs mois quand cela se produit à la fin d'un exercice.
compte tenu des questions que j'ai evoqué par ailleurs, je vais les mettre en exergue sur ce cas :
- graphe d'operations + arbre comptable
- transactions complexes
- index à reecrire alors que le systeme est principalement en ecriture mais necessaire quand meme sinon les recherches ne se finiront jamais.
- impossibilité de naviguer dans un arbre de profondeur indeterminée
- necessité de tables pivots et autres tables intermediaires au kilometre pour palier aux points si dessus
maintenant, pour ma boite, j'avais fait un ptit soft de compta sur mon moteur de graphes pour tenir ma compta, et faire des exports CSV pour mon comptable. j'avais 3 graphes comptables en plus des 5 graphes systemes. actuellement, j'ai repris cette appli incomplete, pour la reprototyper en une appli plus consequente, mais le temps manque.
[^] # Re: explosion du trokilometre
Posté par Mouns . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 2.
pour LDAP et XML ce sont des arbres. un arbre est un graphe non orienté sans cycle.
pour les solutions, je parlais en libre et à ma connaissance. en non libre, j'en connais deux ( tamino et une autre dont j'ai oublié le nom ).
je te concede tout à fait que l'estimation à la dizaine etait trop faible. mais meme aux dizaines cela reste faible. je m'explique.
en guise de preambule, la compta d'un point de vu legale, est l'ajournement de TOUTES les operations numeraires d'une entreprise. dans un modele economique où tout à une valeur numéraire ( d'échange, compensatoire ), la compta devient donc l'ajournement de TOUTES les operations d'une entreprise.
nous avons la compta au bilan, qui donne un etat des mouvements numeraire d'une structure à un instant donné. cette compta permet de construire un bilan de la société. mais le bilan ne donne pas d'autres informations qu'une photo d'un batiment : selon l'angle, la lumiere, la position, on peut ne pas voir la meme chose.
est arrivé la compta analytique au moment de l'industrialisation, pour pouvoir faire des bilans d'unité comptable. l'unité est un centre d'abstraction permetant de voir simplement des transactions sur les autres centres. pareil, selon la maniere de la construire, des pertes deviennent profit et la machine à café 90% de la marge brut :)
il est important de noter que tout mouvement, operation, necessite au moins un emetteur et un recepteur qui se nomment en comptabilite un crediteur et un debiteur. conclusion, une operation peut representer au moins une action de debit et une de credit.
un autre point à comprendre dans la comptabilité : le plan.
le plan ou plan comptable, est l'organisation arborescence des flux numéraires de l'entreprise. la racine du plan est l'agragateur ultime des flux. en gros, la difference, entre deux bilans, permet de donner une mesure des mouvements effectués. attention, cette difference ne mesure que le volume total des flux et non le nombre de flux et ce qu'ils represente.
la racine ne signifie donc rien. il faut donc preciser les flux par une specialisation avec des branches. qui faut continuer de specialiser ... àl'infini.
la compta n'admet qu'une operation mathematique : l'addition de nombres positif ou nul. donc chaque noeud du plan comptable contient deux valeurs : un credit et un debit.
aujourd'hui, quand une entreprise facture en jour-homme, elle peut crediter et debiter des comptes idoines pour avoir un suivi financier du projet assez precis. je tiens à preciser que la granularité temporelle n'est pas un facteur limitant, tu fais ce que tu veux et tu adapte comme tu veux.
si tu veux, une implementation au dessus d'un DNS ou d'un LDAP est possible, mais aujourd'hui, compte tenu des specificités de ces protocoles, la compta n'est pas trop adapté, car elle plus en ecriture qu'en lecture.
et c'est là, qu'apparait le probleme des SGBD et autres FS : aujourd'hui, tout le monde sait faire des lectures simultanées en garantissant la coherence, mais les ecritures simultannées rapide garantissant la coherence, tiennent de la gageure.
je te donne un exemple :
la constitution d'une SARL d'un point de vu comptable :
voici les comptes ( chaque chiffre represente une navigation dans le plan comptable , comme un XPath )
debit | credit
--------------------------------- promesse d'apports
45611
45615
101
--------------------------------- constitution du fond avec les apports
2* (immobilisation)
3* (stock)
45611
----------------------------------- sequestre des fonds
467
45615
----------------------------------- deblocage des fonds
512
467
------------------------------------ frais de constitution
2011
447
donc, il faut au moins 12 mouvements sur 9 feuilles comptables, qui réagrégé, representent au moins 41 mouvements sur le plan. comme tu as pu le constaté, les operations effectuées peuvent etre agrégé en une super operation : comme pour coder, nous avons un graphe d'appel des primitives comptables pour pouvoir faire des "scripts" comptables et operer rapidement.
comme c'est un cas facile et assez trivial, je te laisse imaginer pour la gestion d'une SSII, la comptabilisation d'une prestation au forfait jourhomme en cas de depassement de delai avec compensation financiere ventilé sur plusieurs mois quand cela se produit à la fin d'un exercice.
compte tenu des questions que j'ai evoqué par ailleurs, je vais les mettre en exergue sur ce cas :
- graphe d'operations + arbre comptable
- transactions complexes
- index à reecrire alors que le systeme est principalement en ecriture mais necessaire quand meme sinon les recherches ne se finiront jamais.
- impossibilité de naviguer dans un arbre de profondeur indeterminée
- necessité de tables pivots et autres tables intermediaires au kilometre pour palier aux points si dessus
maintenant, pour ma boite, j'avais fait un ptit soft de compta sur mon moteur de graphes pour tenir ma compta, et faire des exports CSV pour mon comptable. j'avais 3 graphes comptables en plus des 5 graphes systemes. actuellement, j'ai repris cette appli incomplete, pour la reprototyper en une appli plus consequente, mais le temps manque.