si un systeme insatisfaisant est en place :
- tu promets de le changer si tu es elu
- tu te fais elir la dessus
- tu commence à faire semblant de le changer
- puis tu le renforce parce qu'il n'est pas possible de le faire autrement
Disclaimer :
toute ressemblance avec des pouvoirs deja en place est purement fortuite
dire si un nombre est premier ... c pas simple de faire qq chose de performant. mais il y a des algos naif qui sont facile a coder.
trouver N nombres premiers rentre dans la meme categorie avec ln(N)/ln(2) < 32
le meilleur langage de programmation pour apprendre reste de ne pas en apprendre un tout de suite mais de faire de l'algorithmie haut niveau et bas niveau, et pour les plus courageux de faire des circuits logiques et les chronogrammes qui vont avec.
C'est une bonne chose que de l'argent frais s'injecte dans cette société
dire que je pensais que l'argent n'avait pas d'odeur et ne pouvait se dépérir ...
c'est indubitablement la preuve que les financiers et les actionnaires lui font confiance
quand on doute d'une preuve, c'est qu'elle manque ... de preuves :)
la confiance à se niveau est purement spéculatif, une boite qui fait +170% en 6 mois et dont le volume de vente sur les 5 derniers jours est de l'ordre de "3 730", "10 832", "58 950", "41 820", "10 262" et qu'il arrive à faire +23% comme ça ... ça me rappelle une certaine époque recente que certains n'ont pas connu de se point de vue ...
ce qui prouve donc que le modèle économique du Libre est viable
mais oui ! et la marmotte ? elle est ou la preuve ?
tu sais, une preuve avec une démonstration ... comme ce que l'on demande à une personne de raison et non de foi ...
surtout en ces lendemains d'explosion de bulle internet
j'ai comme l'impression que +170% en 6 mois ne te traumatise pas plus que ça ... tu te souviens du CAC 40 à une certaine époque ? et de sa croissance ... +170 % c vraiment pas courant ...
ce qui peut se resumer en "le complot de ceux que j'identifie comme differents de ce que je pense etre" : cela a le doux nom de "paranoïa xenophobe".
dans tous les cas, le complot n'existe que dans la tete de celui qui le voit. mais vu que c des malades qui se sentent opprimés, la seule possibilité est de les laisser en liberté tant qu'ils ne sont pas violent, car en les enfermant cela cristalise et justifie l'absurde ( aka "encore une preuve ! ils veulent me faire taire parce que je sais" ).
à ma connaissance, ici, les commentaires sont automoderés : ce sont les lecteurs les moderateurs.
( je risque de me faire moincir pour ca ), j'ai l'impression que certains tendent les batons pour se faire battre par les autres lecteurs.
il me semble evident que con-fr.org aurait peu de visiteurs ( sauf redefinition du mot "con" ( deja redefini autrefois ) ). mais ce sont les cons qui alimentent les pensées de ceux qui ont l'impression de ne pas en etre. ca me fait penser à une nouvelle du debut des seigneurs de l'intrumentalité ...
- avons nous les sources de l'univers sans reverse engeneering ?
- pouvons nous patcher ?
- avons nous le droit d'avoir notre propre univers ?
- pouvons nous distribuer les sources de l'univers à d'autres univers ?
conclusion je suis sur que le Dieuveloppeur et l'amdieunistrateur supreme ne sont pas de libristes et Bill Gates est à leur solde !
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.
tu parle de "mapping" ... comme c'est etrange ... ;)
puisque Merise est en chute libre, parlons d'UML . comment modelise tu un diagramme de classes de données avec heritage multiple ?
l'ordre de la dizaine ... d'accord ... si je te dis chiche ?
sachant que j'ai posé le contexte jusqu'au paquet de nouille dans carrefour, je te propose d'implementer ta solution de "l'ordre de la dizaines de table" pour un carrefour classique ( mais virtuel ) qui dispose d'une quarantaine de caisse (dont il a besoin pour encaisser et non decorer ), qui gere son stock ( operation de cout technique du stock et de gestion ) avec les dates de limite de vente et de consommation ( operation comptable de depreciation des stocks ), les passages à la caisse, et les vols en tout genre ( perte seche assuré ), gestion des taxes ( TVA, IS, CSG, RDS ), gestion des RH ( horraires, salaires, primes, heures sups, ... ), gestion des provision sur risque ( incendie, hygiene, innondation, ... ) je te pose le plan comptable en vigueur en france cad le PGC 99, et nous n'aborderons pas les normes IAS. je te simplifie les choses en disant qu'il n'y a pas de pertes aux changes, cad que tout operation est en monnaie locale, et que les problemes de consolidation et d'integration ne se posent pas non plus.
tout ca tiens sur des graphes, par contre, le fait de le faire sur un modele relationnel devient tout d'un coup plus embetant :)
les SGBDO sont une alternative au relationnel "dur" pour les problematiques autour des arbres et des graphes. mais regarde LDAP + LDIFF, les implementations sont assez absconses et lourde.
Pour du XML, tu as Xindice de Apache, qui a du mal avec des fichiers XML de plus de 5 Mo . il y avait un projet d'Ideal-X sur les SGBD XML .
le modele relationnel est un modele ensembliste contrairement au modele hierarchique.
le modele hierarchique est une extension contextuelle du modele plat et du modele (clé,valeur).
en gros cela permet de creer des cascades d'espaces plat, une cascade de dbm ou ldiff par exemple.
le modele relationnel lui, pose des ensembles d'attributs, que l'on associe in extenso, dans des espaces tabulaires. à partir de là, on fait des operations ensemblistes sur des selections ( ensembles ) d'ensembles.
vient apres le modele des bases objets, qui est une extension du modele hierarchique, au detail pret, qu'il doit y avoir plusieurs maniere de naviguer dans l'abre.
l'objet relationnel et le relationnel objet sont deux tendances actuelle pour tenter de marier le navigationnel et le relationnel : en gros pouvoir dire je navigue à partir d'une selection ou je selectionne à partir d'un pointeur.
le XML est une normalisation des flux seriels pour pouvoir envoyer des grappes d'objets DOM. DOM n'etant qu'une API permettant d'interroger n'importe quel objet.
l'avantage du XML est que si tu consideres ta table relationnelle comme un agregat d'agregat, tu peux faire une transposition relationnelle <-> navigationnelle.
le but du modele relationnel est de synthetiser par groupe des relations fortes et en extraire des relations deduites par simple operations ensemblistes sur les relations.
quand on prend Merise dans sa definition, il ne correspond pas à l'application de Merise sur du modele relationnel. A cause du probleme des relations many/many . ce qui necessite l'introduction de tables pivot.
dans le cadre d'une application de gestion d'entreprise, nous avons :
- un arbre absolu nommé plan comptable
- un arbre ajourné nommé flux comptable
- un graphe des operations ajournées nommé "operations"
- un graphe de modeles d'operations
sachant que ces graphes et arbres se superposent mutuellement.
donc je te laisse faire un rapide compte du nombre de tables en relationnel.
si tu rajoute en plus du modele de comptabilité au bilan, une comptabilité analytique. tu as une explosion du nombre de tables.
Ajoute maintenant, que toute operation dans une entreprise represente un flux comptable et donc dois etre ajourné, que les ecritures ( qui sont des transactions ) dans une table d'un SGBDR SQL sont couteuses, tu comprendras qu'il faille necessairement des tables de sotckage qui sont agregé et agrégé et agrégé pour chacun des flux. avec le probleme de l'integrite referentiel au commit, cela empire.
maintenant, je rajoute une info, sur un systeme, comptable le rapport lecture/ecriture est tres proche du 1:1 et limite Write Only pour les tres gros systemes ( tracage du paquet de nouille dans un carrefour ).
pour en revenir a SQLite, je n'ai rien contre. si un jour je dois l'utiliser, je l'utiliserai sans etat d'ame. je ne suis pas un idealiste integriste, je suis aussi pragmatique.
je tiens a rajouter que si tu me garantie un salaire mensuel suffisant, je participe à tous les projets que tu désires. souhaites tu me faire une proposition ? ;)
XML ne permet que de faire des arbres pas des graphes.
par contre le projet sur lequel je bosse, permet de modeliser des multigraphes orientés. je planche aussi sur l'implementation des hypergraphes, pour le moment, je le fais par insertion du noeud dual à l'hyperlien à representer.
pour info, c'est vendu depuis 9 ans, et la tenu en charge me semble correct.
sur la version CVS actuelle, je bosse sur la gestion de version et de transaction. l'implemantation des cluster de replication et distribution sont en validation. pour les transactions imbriqués, je verrais plus tard ( aka gestion de dependances sur version ).
si tu es interessé dlfp+unchiffre@mouns.freesurf.fr.
"tout ça reste valable pour l'écrasante majorité des applications présentes sur un poste de bureau sous Linux".
peux tu me faire une liste non exaustive mais equitable à tes yeux d'applications etant dans les deux cas sus sités ?
pour le dev :
RSS = OK dans les cas basique sinon un RSS est un arbre
News = arbre
album photo = graphe
tableur = OK sur une feuille ... sinon ca peut devenir un graphe
je ne me prononcerai pas sur le "montage video", car je n'en ai jamais fait et ne sais meme pas en quoi cela consiste.
le cas de la fermeture transitive, tu la trouve avec tout logiciel usant du modele relationnel pour representer des arbres et des graphes. le cout d'une fermeture transitive sur 10 noeuds est moins perceptible qu'une fermeture transitive sur 10 000 noeuds.
pour te donner une approximation theorique de la volumetrie à traiter :
sur un jointure simple sur elle meme la table resultant est en Card( table ) * Card( Table ) avant selection, sur une fermeture transitive, elle est en Card( table ) ^ Card( Table ). pour 10 elements ca fait un 1E10 et dans le cas de 10 000 ce quit fait 1E40000 .
pour info, je gere des arbres de 124 364 noeuds ( ce matin ) sur lequel je fais des fermetures transitives tres regulierement : heureusement que cela n'est pas modelé sur du relationnel ( sauf si tu arrives à le faire en moins de 2 min 53 ).
je me trompe peut etre, mais j'ai l'impression que tu n'as pas compris ce que j'essaie de dire dans chacune de mes questions. elles posent les problemes suivant :
- faiblesse du modele sur une operation "naturelle"
- lenteur
- impossibilité de naviguer rapidement sans index
- ralentissement dû aux index
- rapport signal/bruit aux niveaux des tables tendant rapidement vers 0 ( un bon exemple est les 12 000 tables de SAP/V3 )
le modele relationnel est tres bien pour certaines chose, mais je maintiens que cela n'est pas une panacée.
PS : la fermeture transitive est juste le fait de derminer la filiation des tuples. pour reprendre un de tes exemples
tu dois faire une fermeture transitive pour connaitre le thread d'une niouze USENET via le champ "References"
le principe du lock fichier est un principe de lock atomique dans le cadre d'absence de gestion de la copie d'edition.
tu fais la meme chose sur un CVS avec "edit" et "unedit". une maniere de gerer cela sur un SGBD vient à n'avoir qu'une transaction effective sur un element ( base, table, tuple, attribut ), et de faire une copie de l'element concerné pour le remplacer au COMMIT. le Copy On Write permet d'aleger le systeme et de le rendre plus veloce.
Par contre avec la notion de copie des transactions, cela evite d'avoir un readlock sur l'element en cours de transaction et donc de garantir l'integrite et l'atomicite du commit. avec un readolck le commit n'est plus atomique mais devient element transactionnel qui doit etre annulé en cas de readlock. ce qui fait dans le cas de SQLite, le code erreur retourné pour rejouer plus tard la transaction.
conclusion dans un systeme critique à lecture forte, le commit n'est pas priorisé et peut en cascade, perturber l'integrité globale d'un systeme.
il ne peut y avoir plus d'un acces simultané en ecriture sur un element.
etant donné l'impossibilité dans les fondements du modele relationel, de faire une fermeture transitive, il est impossible de mettre un verrou sur un tuple et maintenir l'integrite referentielle.
tout au plus, il est possible de mettre un lock sur les tables concernés jusqu'à une certaine profondeur. ou par mesure de securité, mettre un verrou sur la base elle meme.
la solution pour gerer ca, serait de mettre des versions de tuples. à partir de là, il est possible d'avoir une trace temporelle dans la base. par contre cela necessite d'ajourner l'evolution des jointures.
pour le moment, je ne connais pas de solution type "SQL over CVS/arch/subversion". pour le contraire, il y a les Wiki SQL, mais l'integrité du contenu n'est pas garantie.
pour le second point, MDR PTDR LOL ROTLF ! le lock en lecture ca devrait etre breveté ! chepa, au royaume de la photocopie, du P2P, de l'industriel à l'instar du sur mesure, dire cela merite un certain courage, et puis faire du Copy On Write n'est pas si compliqué.
"La puissance du modèle relationnel va vous permettre d'améliorer les performance de votre application sans aucun effort"
"- soit l'accès aux informations à traiter est trop lent : créez tout simplement un index supplémentaire adapté aux besoins"
"- soit le traitement de ces informations est trop lent : créez une ou plusieurs vues qui assurent un pré-traitement de l'information... c'est aussi simple que ça !"
"Vous n'aimez pas le relationnel ? Utilisez une couche de persistance (comme SQLObject en python) qui donne une représentation objet à vos données stockées via SQLite, et cessez d'utilisez ce prétexte, boudiou !"
donc, si c'est si simple, peux tu :
- me faire une fermeture transitive sur un arbre de 10 000 noeuds puis sur un graphe ( non fortement connexe ) contenant des cycles du meme nombre de noeuds
- m'expliquer pourquoi les ecritures coutent plus et que c'est pire lors de transactions, et catastrophique en simultanées
- m'expliquer comment avoir une approche navigationnelle dans une archi relationnelle
- m'expliquer l'effondrement des bases à ecritures lourdes si elles ont trop d'indexation
- me dire le pourquoi de la multitude de tables pivot et autres tables d'etat
le relationnel n'est pas une panacée, et ces 5 questions expose certains points faibles theoriques et pratiques du modele.
[^] # Re: Et le café ?
Posté par Mouns (site web personnel) . En réponse au journal L'Open Source sur CNN. Évalué à -1.
a tout de suite ... j'arrive
# une idee comme ca ...
Posté par Mouns (site web personnel) . En réponse au journal Mainframe à partir de PC ?. Évalué à 2.
un Mosix + UML me semble etre un bon depart
voir un Mosix + UML + Mosix pour reduire encore le risque de deni de service.
mais bon, c pas encore au point tout ca. :(
[^] # Re: Littérature
Posté par Mouns (site web personnel) . En réponse au journal SYSTÈME D'INFORMATION SCHENGEN II. Évalué à 1.
- tu promets de le changer si tu es elu
- tu te fais elir la dessus
- tu commence à faire semblant de le changer
- puis tu le renforce parce qu'il n'est pas possible de le faire autrement
Disclaimer :
toute ressemblance avec des pouvoirs deja en place est purement fortuite
[^] # Re: pas le perl
Posté par Mouns (site web personnel) . En réponse au journal apprendre à programmer... Évalué à 1.
trouver N nombres premiers rentre dans la meme categorie avec ln(N)/ln(2) < 32
le meilleur langage de programmation pour apprendre reste de ne pas en apprendre un tout de suite mais de faire de l'algorithmie haut niveau et bas niveau, et pour les plus courageux de faire des circuits logiques et les chronogrammes qui vont avec.
( qui a dit MMIX ? )
# heu ...
Posté par Mouns (site web personnel) . En réponse au journal Mandrake semble aller à merveille. Évalué à 6.
dire que je pensais que l'argent n'avait pas d'odeur et ne pouvait se dépérir ...
c'est indubitablement la preuve que les financiers et les actionnaires lui font confiance
quand on doute d'une preuve, c'est qu'elle manque ... de preuves :)
la confiance à se niveau est purement spéculatif, une boite qui fait +170% en 6 mois et dont le volume de vente sur les 5 derniers jours est de l'ordre de "3 730", "10 832", "58 950", "41 820", "10 262" et qu'il arrive à faire +23% comme ça ... ça me rappelle une certaine époque recente que certains n'ont pas connu de se point de vue ...
ce qui prouve donc que le modèle économique du Libre est viable
mais oui ! et la marmotte ? elle est ou la preuve ?
tu sais, une preuve avec une démonstration ... comme ce que l'on demande à une personne de raison et non de foi ...
surtout en ces lendemains d'explosion de bulle internet
j'ai comme l'impression que +170% en 6 mois ne te traumatise pas plus que ça ... tu te souviens du CAC 40 à une certaine époque ? et de sa croissance ... +170 % c vraiment pas courant ...
[^] # Re: -42
Posté par Mouns (site web personnel) . En réponse au journal Pétition contre le système de modération de Linuxfr. Évalué à 9.
- le complot des pigeons roux
- le complot judeo maconnique
- le complot communiste
- le complot rosicrucien
- le complot des pauvres
- le complot des riches
- le complot microsoft
- le complot FSF, GNU, GPL
- le complot open source
- le complot des petits gris
- le complot des chats
- le complot des rats
- le complot des autres
ce qui peut se resumer en "le complot de ceux que j'identifie comme differents de ce que je pense etre" : cela a le doux nom de "paranoïa xenophobe".
dans tous les cas, le complot n'existe que dans la tete de celui qui le voit. mais vu que c des malades qui se sentent opprimés, la seule possibilité est de les laisser en liberté tant qu'ils ne sont pas violent, car en les enfermant cela cristalise et justifie l'absurde ( aka "encore une preuve ! ils veulent me faire taire parce que je sais" ).
à ma connaissance, ici, les commentaires sont automoderés : ce sont les lecteurs les moderateurs.
( je risque de me faire moincir pour ca ), j'ai l'impression que certains tendent les batons pour se faire battre par les autres lecteurs.
il me semble evident que con-fr.org aurait peu de visiteurs ( sauf redefinition du mot "con" ( deja redefini autrefois ) ). mais ce sont les cons qui alimentent les pensées de ceux qui ont l'impression de ne pas en etre. ca me fait penser à une nouvelle du debut des seigneurs de l'intrumentalité ...
[^] # Re: Yeah !
Posté par Mouns (site web personnel) . En réponse au journal DLFPToolbar Reloaded. Évalué à 0.
et je n'ai pas fait qu'un test ...
[^] # Re: Yeah !
Posté par Mouns (site web personnel) . En réponse au journal DLFPToolbar Reloaded. Évalué à 4.
moz 1.7 :
A - 10152
B - 15174
epiphany :
A - 6051
B - 2530
ya comme une couille dans le moz 1.7 de debian =)
[^] # l'univers sapuspalibre
Posté par Mouns (site web personnel) . En réponse au journal Idées de brevets. Évalué à 4.
- pouvons nous patcher ?
- avons nous le droit d'avoir notre propre univers ?
- pouvons nous distribuer les sources de l'univers à d'autres univers ?
conclusion je suis sur que le Dieuveloppeur et l'amdieunistrateur supreme ne sont pas de libristes et Bill Gates est à leur solde !
[^] # Re: explosion du trokilometre
Posté par Mouns (site web personnel) . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 1.
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[^] # Re: explosion du trokilometre
Posté par Mouns (site web personnel) . 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.
[^] # Re: explosion du trokilometre
Posté par Mouns (site web personnel) . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 1.
puisque Merise est en chute libre, parlons d'UML . comment modelise tu un diagramme de classes de données avec heritage multiple ?
l'ordre de la dizaine ... d'accord ... si je te dis chiche ?
sachant que j'ai posé le contexte jusqu'au paquet de nouille dans carrefour, je te propose d'implementer ta solution de "l'ordre de la dizaines de table" pour un carrefour classique ( mais virtuel ) qui dispose d'une quarantaine de caisse (dont il a besoin pour encaisser et non decorer ), qui gere son stock ( operation de cout technique du stock et de gestion ) avec les dates de limite de vente et de consommation ( operation comptable de depreciation des stocks ), les passages à la caisse, et les vols en tout genre ( perte seche assuré ), gestion des taxes ( TVA, IS, CSG, RDS ), gestion des RH ( horraires, salaires, primes, heures sups, ... ), gestion des provision sur risque ( incendie, hygiene, innondation, ... ) je te pose le plan comptable en vigueur en france cad le PGC 99, et nous n'aborderons pas les normes IAS. je te simplifie les choses en disant qu'il n'y a pas de pertes aux changes, cad que tout operation est en monnaie locale, et que les problemes de consolidation et d'integration ne se posent pas non plus.
tout ca tiens sur des graphes, par contre, le fait de le faire sur un modele relationnel devient tout d'un coup plus embetant :)
les SGBDO sont une alternative au relationnel "dur" pour les problematiques autour des arbres et des graphes. mais regarde LDAP + LDIFF, les implementations sont assez absconses et lourde.
Pour du XML, tu as Xindice de Apache, qui a du mal avec des fichiers XML de plus de 5 Mo . il y avait un projet d'Ideal-X sur les SGBD XML .
pour les graphes, ...
[^] # Re: pfff
Posté par Mouns (site web personnel) . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 1.
Oups, ca s'appelle une base XML ca :)
[^] # Re: pfff
Posté par Mouns (site web personnel) . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 3.
le modele hierarchique est une extension contextuelle du modele plat et du modele (clé,valeur).
en gros cela permet de creer des cascades d'espaces plat, une cascade de dbm ou ldiff par exemple.
le modele relationnel lui, pose des ensembles d'attributs, que l'on associe in extenso, dans des espaces tabulaires. à partir de là, on fait des operations ensemblistes sur des selections ( ensembles ) d'ensembles.
vient apres le modele des bases objets, qui est une extension du modele hierarchique, au detail pret, qu'il doit y avoir plusieurs maniere de naviguer dans l'abre.
l'objet relationnel et le relationnel objet sont deux tendances actuelle pour tenter de marier le navigationnel et le relationnel : en gros pouvoir dire je navigue à partir d'une selection ou je selectionne à partir d'un pointeur.
le XML est une normalisation des flux seriels pour pouvoir envoyer des grappes d'objets DOM. DOM n'etant qu'une API permettant d'interroger n'importe quel objet.
l'avantage du XML est que si tu consideres ta table relationnelle comme un agregat d'agregat, tu peux faire une transposition relationnelle <-> navigationnelle.
[^] # Re: explosion du trokilometre
Posté par Mouns (site web personnel) . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 2.
quand on prend Merise dans sa definition, il ne correspond pas à l'application de Merise sur du modele relationnel. A cause du probleme des relations many/many . ce qui necessite l'introduction de tables pivot.
dans le cadre d'une application de gestion d'entreprise, nous avons :
- un arbre absolu nommé plan comptable
- un arbre ajourné nommé flux comptable
- un graphe des operations ajournées nommé "operations"
- un graphe de modeles d'operations
sachant que ces graphes et arbres se superposent mutuellement.
donc je te laisse faire un rapide compte du nombre de tables en relationnel.
si tu rajoute en plus du modele de comptabilité au bilan, une comptabilité analytique. tu as une explosion du nombre de tables.
Ajoute maintenant, que toute operation dans une entreprise represente un flux comptable et donc dois etre ajourné, que les ecritures ( qui sont des transactions ) dans une table d'un SGBDR SQL sont couteuses, tu comprendras qu'il faille necessairement des tables de sotckage qui sont agregé et agrégé et agrégé pour chacun des flux. avec le probleme de l'integrite referentiel au commit, cela empire.
maintenant, je rajoute une info, sur un systeme, comptable le rapport lecture/ecriture est tres proche du 1:1 et limite Write Only pour les tres gros systemes ( tracage du paquet de nouille dans un carrefour ).
pour en revenir a SQLite, je n'ai rien contre. si un jour je dois l'utiliser, je l'utiliserai sans etat d'ame. je ne suis pas un idealiste integriste, je suis aussi pragmatique.
[^] # Re: explosion du trokilometre
Posté par Mouns (site web personnel) . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 0.
[^] # Re: explosion du trokilometre
Posté par Mouns (site web personnel) . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 0.
[^] # Re: explosion du trokilometre
Posté par Mouns (site web personnel) . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 1.
XML ne permet que de faire des arbres pas des graphes.
par contre le projet sur lequel je bosse, permet de modeliser des multigraphes orientés. je planche aussi sur l'implementation des hypergraphes, pour le moment, je le fais par insertion du noeud dual à l'hyperlien à representer.
pour info, c'est vendu depuis 9 ans, et la tenu en charge me semble correct.
sur la version CVS actuelle, je bosse sur la gestion de version et de transaction. l'implemantation des cluster de replication et distribution sont en validation. pour les transactions imbriqués, je verrais plus tard ( aka gestion de dependances sur version ).
si tu es interessé dlfp+unchiffre@mouns.freesurf.fr.
[^] # Re: explosion du trokilometre
Posté par Mouns (site web personnel) . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 3.
"tout ça reste valable pour l'écrasante majorité des applications présentes sur un poste de bureau sous Linux".
peux tu me faire une liste non exaustive mais equitable à tes yeux d'applications etant dans les deux cas sus sités ?
pour le dev :
RSS = OK dans les cas basique sinon un RSS est un arbre
News = arbre
album photo = graphe
tableur = OK sur une feuille ... sinon ca peut devenir un graphe
je ne me prononcerai pas sur le "montage video", car je n'en ai jamais fait et ne sais meme pas en quoi cela consiste.
le cas de la fermeture transitive, tu la trouve avec tout logiciel usant du modele relationnel pour representer des arbres et des graphes. le cout d'une fermeture transitive sur 10 noeuds est moins perceptible qu'une fermeture transitive sur 10 000 noeuds.
pour te donner une approximation theorique de la volumetrie à traiter :
sur un jointure simple sur elle meme la table resultant est en Card( table ) * Card( Table ) avant selection, sur une fermeture transitive, elle est en Card( table ) ^ Card( Table ). pour 10 elements ca fait un 1E10 et dans le cas de 10 000 ce quit fait 1E40000 .
pour info, je gere des arbres de 124 364 noeuds ( ce matin ) sur lequel je fais des fermetures transitives tres regulierement : heureusement que cela n'est pas modelé sur du relationnel ( sauf si tu arrives à le faire en moins de 2 min 53 ).
je me trompe peut etre, mais j'ai l'impression que tu n'as pas compris ce que j'essaie de dire dans chacune de mes questions. elles posent les problemes suivant :
- faiblesse du modele sur une operation "naturelle"
- lenteur
- impossibilité de naviguer rapidement sans index
- ralentissement dû aux index
- rapport signal/bruit aux niveaux des tables tendant rapidement vers 0 ( un bon exemple est les 12 000 tables de SAP/V3 )
le modele relationnel est tres bien pour certaines chose, mais je maintiens que cela n'est pas une panacée.
PS : la fermeture transitive est juste le fait de derminer la filiation des tuples. pour reprendre un de tes exemples
tu dois faire une fermeture transitive pour connaitre le thread d'une niouze USENET via le champ "References"
[^] # Re: revenons sur terre
Posté par Mouns (site web personnel) . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 4.
tu fais la meme chose sur un CVS avec "edit" et "unedit". une maniere de gerer cela sur un SGBD vient à n'avoir qu'une transaction effective sur un element ( base, table, tuple, attribut ), et de faire une copie de l'element concerné pour le remplacer au COMMIT. le Copy On Write permet d'aleger le systeme et de le rendre plus veloce.
Par contre avec la notion de copie des transactions, cela evite d'avoir un readlock sur l'element en cours de transaction et donc de garantir l'integrite et l'atomicite du commit. avec un readolck le commit n'est plus atomique mais devient element transactionnel qui doit etre annulé en cas de readlock. ce qui fait dans le cas de SQLite, le code erreur retourné pour rejouer plus tard la transaction.
conclusion dans un systeme critique à lecture forte, le commit n'est pas priorisé et peut en cascade, perturber l'integrité globale d'un systeme.
[^] # Re: revenons sur terre
Posté par Mouns (site web personnel) . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 8.
etant donné l'impossibilité dans les fondements du modele relationel, de faire une fermeture transitive, il est impossible de mettre un verrou sur un tuple et maintenir l'integrite referentielle.
tout au plus, il est possible de mettre un lock sur les tables concernés jusqu'à une certaine profondeur. ou par mesure de securité, mettre un verrou sur la base elle meme.
la solution pour gerer ca, serait de mettre des versions de tuples. à partir de là, il est possible d'avoir une trace temporelle dans la base. par contre cela necessite d'ajourner l'evolution des jointures.
pour le moment, je ne connais pas de solution type "SQL over CVS/arch/subversion". pour le contraire, il y a les Wiki SQL, mais l'integrité du contenu n'est pas garantie.
pour le second point, MDR PTDR LOL ROTLF ! le lock en lecture ca devrait etre breveté ! chepa, au royaume de la photocopie, du P2P, de l'industriel à l'instar du sur mesure, dire cela merite un certain courage, et puis faire du Copy On Write n'est pas si compliqué.
# explosion du trokilometre
Posté par Mouns (site web personnel) . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 4.
"- soit l'accès aux informations à traiter est trop lent : créez tout simplement un index supplémentaire adapté aux besoins"
"- soit le traitement de ces informations est trop lent : créez une ou plusieurs vues qui assurent un pré-traitement de l'information... c'est aussi simple que ça !"
"Vous n'aimez pas le relationnel ? Utilisez une couche de persistance (comme SQLObject en python) qui donne une représentation objet à vos données stockées via SQLite, et cessez d'utilisez ce prétexte, boudiou !"
donc, si c'est si simple, peux tu :
- me faire une fermeture transitive sur un arbre de 10 000 noeuds puis sur un graphe ( non fortement connexe ) contenant des cycles du meme nombre de noeuds
- m'expliquer pourquoi les ecritures coutent plus et que c'est pire lors de transactions, et catastrophique en simultanées
- m'expliquer comment avoir une approche navigationnelle dans une archi relationnelle
- m'expliquer l'effondrement des bases à ecritures lourdes si elles ont trop d'indexation
- me dire le pourquoi de la multitude de tables pivot et autres tables d'etat
le relationnel n'est pas une panacée, et ces 5 questions expose certains points faibles theoriques et pratiques du modele.
A chaque probleme sa solution.
# info device reseau
Posté par Mouns (site web personnel) . En réponse au message Avoir le debit d'une connexion. Évalué à 2.
/proc/net/dev
[^] # Re: Benchmark SGDBR
Posté par Mouns (site web personnel) . En réponse au journal Recherche Benchmark SGBD. Évalué à 1.
je te remercie pour ce document. c'est exactement ce que je cherchais.
ca me donne une base de comparaison, et un protocole de test.
[^] # Re: Prix possible...
Posté par Mouns (site web personnel) . En réponse au journal Serveurs INTEL à vendre.... Évalué à 1.
et la livraison se passe comment ?