samedi 11 octobre

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Logiciel

[81] Sortie de Mozilla 1.7
[49] Amarok 1.0 est là !
[53] Premier jeu de cartes en SVG pur
[59] Sortie de Thunderbird 0.7
[40] Gel du codec vidéo Ogg Theora
[138] Firefox 0.9
[43] Mtp-target ou apprenez à votre pingouin comment voler
[20] Nvu 0.30 est sorti
[51] Vim 6.3 dans les bacs.
[15] La fin du gestionnaire de fenêtres Kahakai

Liens connexes

Le projet SQLite (3953 hits)
Changements apportés par la version 3.0 (787 hits)
Un article sur SQLite publiée dans Linuxjournal (1030 hits)
Utilisez SQLite avec le langage de votre choix (2136 hits)
Liste non-exhaustive des projets utilisant SQLite (1573 hits)

Dépêche modérée par

Logiciel : Ça bouge du côté de SQLite !

Posté par bobert (). Modéré le 19 juin 2004.

La version 3.0 vient de sortir. Encore au stade alpha, elle apporte de nouvelles fonctionnalités, des performances accrues ainsi qu'une occupation disque réduite d'environ 30%... rien de moins !

SQLite est un moteur libre de base de données relationnelles aux possibilités fantastiques. Disons en deux mots qu'il a tout d'un grand, mais avec une empreinte mémoire de 125 ko... et en n'utilisant qu'un unique fichier de stockage !

Le recours à l'une de ses deux extensions client-serveur existantes permet d'utiliser SQLite au sein d'une application web. Mais là où SQLite se révèle imbattable, c'est embarqué au sein d'une application : on bénéficie ainsi de toute la puissance d'un moteur relationnel et du langage SQL, tout ça sans avoir déployé aucun serveur, puisque tout tient dans un unique fichier, tables, vues, index, etc...

Je profite donc de cette news pour encourager vivement tout développeur de logiciel libre à considérer sérieusement l'usage de SQLite dans son application : laisser à un moteur dédié le soin de stocker ses données, c'est pertinent pour toutes les applications, pas seulement pour le client-serveur. Et dans cette optique, SQLite est en passe de devenir incontournable...

NdM : SQLite est dans le domaine public.

Le projet SQLite (3953 hits)
Changements apportés par la version 3.0 (787 hits)
Un article sur SQLite publiée dans Linuxjournal (1030 hits)
Utilisez SQLite avec le langage de votre choix (2136 hits)
Liste non-exhaustive des projets utilisant SQLite (1573 hits)

> Lire la suite (140 commentaires, moyenne: 3,4). [dépêche : 5692 caractères]

Nouveautés de la version 3.0

Voyons rapidement la liste des nouveautés apportées par cette version 3.0 :
- Un nouveau format de fichier de stockage -> 25 à 35 % plus compact
- Les données sont maintenant typées ; les types de données possibles sont: INTEGER, REAL, TEXT et BLOB
- Support de l'Unicode, via les encodages UTF-8 et UTF-16
- Support amélioré des accès concurrents : désormais, un processus peut commencer à écrire dans la base alors que d'autres processus continuent d'y lire

La liste complète des changements est dans les liens.

Les grandes caractéristiques de SQLite

Sans se substituer à la page du projet, je reprend ici les caractéristiques marquantes de SQLite :
- Implémente la plus grande partie de la norme SQL92, dont les triggers et les transactions
- Une base de données entière est stockée dans un seul fichier
- Supporte les transactions avec toutes les propriétés d'atomicité, de consistence, d'isolation et de durabilité (ACID)
- Peut gérer des bases de données d'une taille allant jusqu'à 2 téra octets
- Le code source n'a aucune dépendance externe ; il est portable vers de nombreuses plates-formes
- Offre des performances supérieures à PostgreSQL et même MySQL pour beaucoup de types de requêtes communes
- Des "wrappers" à la bibliothèque de SQLite ont été écrits dans une tonne de langages, vous êtes sûrs de pouvoir utiliser SQLite en codant dans le langage de votre choix
- Des polites sont également disponibles pour LIBDBI, JDBC, et ODBC

SQLite et accès concurrentiels

J'attire votre attention sur le fait qu'il est maintenant possible d'utiliser SQLite au sein d'un application web. Plusieurs personnes (voir par exemple ce journal ont eu des difficultés lors d'accès concurrentiels à SQLite). Deux extensions client-serveur sont maintenant disponibles :
- SQL Relay, utilisable avec plusieurs moteurs de base de données
- SQLite on Sockets, spécifique à SQLite, est un projet tout jeune, puisqu'il a été annoncé seulement avant-hier ! Le développeur principal rencontre semble-t-il quelques problèmes liés à pthreads, alors n'hésitez pas à lui filer un coup de main !

Domaines d'utilisation de SQLite

- Applications web, sites web
- Comme base de donnée embarquée dans un téléphone portable ou un PDA
- Comme base de donnée "embarquée" au sein d'une application

J'aimerais souligner la pertinence de l'emploi de SQLite comme couche logique de stockage des données d'une application... amis développeurs, ceci s'addresse à vous !
- vous y perdez peut-être en facilité de mise en oeuvre, du moins lorsque l'application en est à ses débuts
- mais considérez une seconde tout ce que vouz y gagnez :

1. La fiabilité.
La robustesse de SQLite n'est plus à prouver ; quand aux opérations d'écriture, elles offrent comme dit plus haut toutes les caractéristiques transactionnelles désirées.

2. Offrir à l'utilisateur un niveau illimité d'annuler/refaire

Les utilisateurs, moi le premier, sont habitués aux entrées de menu "Édition->annuler" et "Édition->refaire"... ça en est devenu tellement banal qu'on ne s'imagine pas la difficulté d'implémenter un bête undo/redo dans une application... vous avez déjà essayé, et vous avez renoncé, peut-être ?

Imaginez maintenant que vous ayez prévu des triggers dans votre base de données, qui enregistrent chaque action de votre utilisateur dans une table undo/redo temporaire... eh bien voilà, en utilisant SQLite, il n'en faudrait pas plus pour offrir cette possibilité !

3. Performances.
Sans rien faire, il y a des chances que SQLite soit plus rapide que vous pour accéder aux informations dont vous avez besoin. Mais supposons qu'une partie de votre application soit trop lente pour une fonctionnalité donnée. La puissance du modèle relationnel va vous permettre d'améliorer les performance de votre application sans aucun effort: d'une manière générale, il s'agit de récupérer des informations, de les traiter, et éventuellement de stocker le résultat. Eh bien, la plupart du temps:
- 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 !

4. Donnez à votre application une architecture plus soignée.
En séparant la couche logique de stockage de vos données du reste, vous aurez un code beaucoup plus simple à maintenir et à étendre.

Vous ne connaissez pas SQL ? Commencez à vous y mettre, sincèrement pour des besoins simples les requêtes équivalentes sont triviales, et pour des besoins plus complexes vous trouverez sur le net des gens disposés à vous aider... ça ne doit surtout pas vous arrêter.

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 !

Voilà, en espérant vous avoir persuadé que SQLite est une aubaine pour les logiciels libres de toutes sortes. Richard Hipp, son principal auteur, nous offre là une petite merveille, dont il serait bien dommage de se priver.
Alors participez à la campagne de test de cette toute fraîche version 3.0, et mangez-en... à toutes les sauces !

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Pub

Posté par ftp (page perso, ) le 19/06/2004 à 15:28. (lien). Évalué à 19.

J'ai jamais ralé sur la partialité d'une news mais là...
Même les plus fanatiques de KDE/Gnome/Mandrake/SuSE/Emacs/Vim/Windows ne sortent pas des choses comme encourager vivement tout développeur de logiciel libre à considérer sérieusement l'usage de SQLite dans son application dans leur news...

-1 parce que trop raleur

[^]Re: Pub

Posté par Pinaraf (Jabber id, ) le 19/06/2004 à 16:19. (lien). Évalué à 20.
Hormis ce grave manque de partialité et cet enthousiasme trop débordant qui lui fait dire des bêtises (cf posts d'en dessous), je trouve cet news très bonne : changelog réduit mais suffisant, bonne présentation du produit, à quoi il sert...
Il faudrait que plus de news soient aussi complètes !

[^]Re: Pub

Posté par Guillaume Knispel () le 19/06/2004 à 20:22. (lien). Évalué à 1.
Personnellement j'éviterais à encourager quiquonque à contribuer pour du non copyleft pouvant être récupéré par des éditeurs de logiciels propriétaires, mais bon, chacun ses encouragements ?
- [^]Re: Pub
  
  Posté par Pierre Jarillon (page perso, ) le 20/06/2004 à 01:04. (lien). Évalué à 8.
  C'est ce qui est arrivé à postgresql. Ingres n'est qu'un fork propriétaire de postgres.
  Le but des licences BSD est de permettre aux étudiants de poursuivre leur travail sous licence propriétaire de et créer leurs entreprises. Dans le cas de Ingres, ça a fonctionné, mais ce n'a rien rapporté en retour à postgresql.
  Je pense aussi que le copyleft (GPL) est bien préférable et les modèles économiques commencent à apparaitre.
  
  Il semble qu'une très bonne méthode est de donner le téléchargement gratuit de la version n-1 et de fournir sous licence GPL la version la plus à jour à ses clients.
  C'est autour de cette formule que fonctionne une société comme IdealX pour PKI.
  Ryxeo (avec Abuledu) et Mandrake ont aussi des politiques voisines entièrement sous GPL (pour leurs logiciels) et démontrent que ce sont des solutions viables.
  Une autre méthode est la double licence pratiquée par MySQL-AB et Trolltech.
  
  Voici pourquoi si je comprend l'objectif de la licence BSD, je crois beaucoup plus à l'avenir de la GPL
  - [^]Re: Pub
    
    Posté par Antoine () le 20/06/2004 à 09:46. (lien). Évalué à 13.
    C'est ce qui est arrivé à postgresql. Ingres n'est qu'un fork propriétaire de postgres.
    
    N'importe quoi. Ingres est un projet universitaire des années 70.
    
    « Ingres was an early relational database system, created as a research project at the University of California, Berkeley starting in the early 1970s and ending in the early 1980s. The code, like that from other projects at Berkeley, was available at minimal cost under a version of the BSD license. Since the mid-1980s, Ingres had spawned a number of commercial database applications, including Sybase, SQL Server, NonStop SQL, Informix and a number of others. A follow-on project started in the mid-1980s as Postgres, leading to the development of PostgreSQL, Illustra, and later versions of Informix. »
    
    http://en.wikipedia.org/wiki/Ingres(...)
    - [^]Re: Pub
      
      Posté par Pierre Jarillon (page perso, ) le 26/06/2004 à 10:15. (lien). Évalué à 2.
      Alors allons voir aussi : http://en.wikipedia.org/wiki/PostgreSQL(...) :
      
      « PostgreSQL has had a lengthy evolution, starting with the Ingres project at UC Berkeley. The project lead, Michael Stonebraker had left Berkeley to commercialize Ingres in 1982, but eventually returned to academia. After returning to Berkeley in 1985, Stonebraker started a post-Ingres project... »
      
      Dans le manuel de Posgresql, on peut lire dans la préface :
      
      « What is PostgreSQL?
      PostgreSQL is an object-relational database management system (ORDBMS) based on POSTGRES, Version 4.2 (http://s2k-ftp.CS.Berkeley.EDU:8000/postgres/postgres.html(...)), developed at the University of California at Berkeley Computer Science Department. The POSTGRES project, led by Professor Michael Stonebraker, was sponsored by the Defense Advanced Research Projects Agency (DARPA), the Army Research Office (ARO), the National Science Foundation (NSF), and ESL, Inc. PostgreSQL is an open-source descendant of this original Berkeley code. It provides SQL92/SQL99 language support and other modern features. »
      
      Il faut noter que le nom Ingres a suivi la branche proprétaire. Il aurait été plus logique de désigner le fork propriétaire par postgres et conserver Ingres pour le projet libre. Mais enfin, si la licence BSD le permet !
  - [^]Re: Pub
    
    Posté par Guillaume Knispel () le 20/06/2004 à 17:30. (lien). Évalué à 6.
    Il semble qu'une très bonne méthode est de donner le téléchargement gratuit de la version n-1 et de fournir sous licence GPL la version la plus à jour à ses clients.
    
    Le gros inconvenient de cette méthode est qu'en faisant ca tu empeches (ou en tout cas limite très fortement) les contributions externes, ce qui limite extrèmement l'interet du libre.
    
    En tout cas personellement je ne contribue jamais à un projet en ne partant pas de la dernière version, du coup je ne contribue jamais à un projet qui utilise ce modèle de distribution...
    - [^]Re: Pub
      
      Posté par Pierre Jarillon (page perso, ) le 26/06/2004 à 10:31. (lien). Évalué à 2.
      Le gros inconvenient de cette méthode est qu'en faisant ca tu empeches (ou en tout cas limite très fortement) les contributions externes, ce qui limite extrèmement l'interet du libre.
      
      C'est vrai, je suis d'accord. Mais c'est aussi une façon d'avoir des clients. Il y a quelques semaines, à Angoulême, Nat Makarevitch nous a expliqué qu'il utilisait actuellement cette méthode pour certains logiciels de IdealX. Son souhait est de ne plus l'utiliser à l'avenir mais il y a des réalités économiques qu'il faut prendre en compte pour qu'une entreprise puisse vivre.
      Avec ce système, les contributeurs naturels sont les clients. Pour des logiciels assez pointus et utilisés dans le monde professionnel cette solution fonctionne et elle est conforme à la GPL. C'est quand même pas mal !
- [^]Re: Pub
  
  Posté par Éric (Jabber id, page perso, ) le 20/06/2004 à 01:04. (lien). Évalué à 7.
  Oui enfin c'est du libre tout de même.
  Je ne suis pas sûr que quiconque ait à y gagner à forcer les éditeurs proprio à redévelopper en interne leur propre solution (parce que je doute qu'ils changent de licence juste pour sqlite).
  Tout est question de philosophie. Tu souhaites développer le libre ou supprimer le propriétaire ?
  - [^]Re: Pub
    
    Posté par Antoine () le 20/06/2004 à 09:48. (lien). Évalué à 4.
    Là ce n'est pas du libre, c'est du domaine public.
    Cela veut dire que tu ne peux même pas demander le respect de la paternité sur un bout de code que tu as écrit (une boîte peut très bien récupérer le code et dire "c'est moi qui l'ai écrit").
    
    En passant, en France un auteur ne peut pas de lui-même décider de placer une oeuvre dans le domaine public (because droit moral incessible).
    - [^]Re: Pub
      
      Posté par renoo () le 20/06/2004 à 11:07. (lien). Évalué à 0.
      "tu ne peux même pas demander le respect de la paternité sur un bout de code que tu as écrit"
      
      Et les livres que tu as lu, et les gens avec qui tu en as discuté, tu penses qu'ils n'ont pas leur part de paternité dans ces quelques lignes ? Comment peut on oser dire c'est moi (et rien que moi) qui l'ai fait et personne ne pourra en faire autre chose que ce que moi je décide.
      
      "Là ce n'est pas du libre, c'est du domaine public."
      
      Mais le domaine public est libre et c'est probablement la license la plus libre existante puisque chacun en fait ce qu'il veut et meme s'en servir pour supprimer la liberté des autres (soit en faisant des logiciels propriétaires)... ce que peut aussi faire le logiciel libre (les logiciels libres peuvent et font etre utilisés par la police et les administrations pénitentiaires).
      - [^]Troll
        
        Posté par Antoine () le 20/06/2004 à 12:12. (lien). Évalué à 2.
        Et les livres que tu as lu, et les gens avec qui tu en as discuté, tu penses qu'ils n'ont pas leur part de paternité dans ces quelques lignes ? Comment peut on oser dire c'est moi (et rien que moi) qui l'ai fait et personne ne pourra en faire autre chose que ce que moi je décide.
        
        La paternité d'une oeuvre se définit par la donnée de celui qui l'a écrite, pas par ceux qui l'ont inspiré. C'est une notion à la fois morale et juridique très précise.
        
        Et, oui, ce que j'ai fait, il n'y a rien que moi qui l'ai fait. Ceux qui l'ont inspiré, de près ou de loin, n'ont pas participé à sa création. Avoir une idée est facile, la concrétiser (sous forme d'une oeuvre) est difficile. Quel que soit le domaine : informatique, littérature...
        
        [^]Re: Troll
        
        Posté par renoo () le 20/06/2004 à 13:45. (lien). Évalué à 3.
        "La paternité d'une oeuvre se définit par la donnée de celui qui l'a écrite, pas par ceux qui l'ont inspiré."
        
        Mais tu reconnaitras quand meme que l'oeuvre n'aurait pas existé sans l'inspiration, sans l'ensemble de ce qui entoure l'auteur qui n'est alors qu'élément dans l'ensemble de la création. Je ne partage pas le point de vue morale qui autorise quelqu'un à limiter la liberté de quelqu'un d'autre (droit de copie, brevets...) et plus globalement je ne crois pas à la propriété intelectuelle, c'est ma morale à moi et je ne suis pas le seul à avoir ce point de vue.. Le problème avec la morale c'est que c'est toujours celle des autres disait Férré.
        
        Tu peux aussi lire la préface de Foucault sur son Histoire de la folie à l'âge classique qui réalise ujne belle critique de la monarchie de l'auteur. http://infokiosques.net/imprimersans.php3?id_article=150(...)
        
        "Avoir une idée est facile, la concrétiser (sous forme d'une oeuvre) est difficile."
        
        Je ne suis pas d'accord, décrire précisement une idée peut etre la grosse partie du boulot, et des dizaines d'idées peuvent ne mener à rien du tout alors qu'une bonne idée se développera facilement.
        
        [^]Re: Troll
        
        Posté par Antoine () le 20/06/2004 à 19:11. (lien). Évalué à 2.
        Je ne partage pas le point de vue morale qui autorise quelqu'un à limiter la liberté de quelqu'un d'autre
        
        Je suis relativement d'accord mais je parlais juste du respect de la paternité, pas du droit à limiter les droits d'utilisation / modification / redistribution...
        
        Le droit moral n'est pas un obstacle à la diffusion des connaissances, il est simplement une reconnaissance du caractère essentiel de l'intervention de l'auteur.
    - [^]Re: Pub
      
      Posté par Éric (Jabber id, page perso, ) le 20/06/2004 à 12:34. (lien). Évalué à 5.
      > Là ce n'est pas du libre, c'est du domaine public.
      
      - tu peux redistribuer
      - tu peux modifier
      - tu peux utiliser
      - tu as accès au code source
      => c'est du libre.
      ça n'empêche pas d'être aussi du domaine public mais c'est du libre.
      
      > Cela veut dire que tu ne peux même pas demander le respect de la
      > paternité sur un bout de code que tu as écrit
      
      Si tu es français RIEN ne peut te retirer la paternité de ce que tu fais, même pas toi. Et comme dit quelqu'un plus bas moi je vois souvent l'Odyssee dans les librairies, c'est u domaine public mais je vois toujours le nom de l'auteur présumé.
      
      Mais peu importe, c'est le code de départ qui est sous domaine public. Et justement le domaine public ça autorise tout.
      Donc si jamais tu écris quelque chose avec/dans SQLite tu as toute liberté d'y mettre une licence qui convient à tes principes. Une qui oblige à citer l'auteur par exemple.
      
      > (une boîte peut très bien récupérer le code et dire "c'est moi qui l'ai écrit").
      
      Certainement pas. Tu peux ne pas marquer explicitement le nom de l'auteur, mais si je dis que c'st moi l'auteur alors que c'est toi tu peux tout à fais m'attaquer. Domaine public ou pas c'est une fausse affirmation.
      - [^]Re: Pub
        
        Posté par gnujsa () le 20/06/2004 à 15:52. (lien). Évalué à 5.
        Et c'est même compatible GPL:
        « Public domain status is compatible with the GNU GPL.»
        
        http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses(...)
        
        [^]Re: Pub
        
        Posté par Bière Drabo () le 20/06/2004 à 16:07. (lien). Évalué à 2.
        A condition d'avoir les sources. Le domaine public fermé, ça existe aussi...
        
        [^]Re: Pub
        
        Posté par supergab () le 20/06/2004 à 17:14. (lien). Évalué à 3.
        Il est possible de prendre le code de SQLite et de le distribuer sous une licence GPL. Si vous croyez que le copyleft est si important, faites-le.
        
        [^]Re: Pub
        
        Posté par Antoine () le 20/06/2004 à 19:12. (lien). Évalué à 2.
        Il est possible de faire pareil avec un BSD. Le problème est simplement que les gens qui veulent contribuer à SQLite (sans forker) doivent, eux, accepter de perdre absolument tous leurs droits en tant qu'auteurs.
        
        [^]Re: Pub
        
        Posté par Éric (Jabber id, page perso, ) le 20/06/2004 à 20:10. (lien). Évalué à 2.
        En quoi on perd plus de droits avec un soft sous GPL qu'un soft sous BSD ? De quels droits parles tu ?
        Tu autorises plus ou moins de gens à diffuser mais ça ne change rien à tes droits.
        
        D'ailleurs quand tu contribue à un projet GPL mené par une boite on te demande assez souvent de donner tous tes droits pour que ce soit intégré dans l'arbre global (pour que la boite reste libre de sa politique de licence ou puisse continuer à faire de la double licence).
        
        [^]Re: Pub
        
        Posté par Antoine () le 20/06/2004 à 21:54. (lien). Évalué à 2.
        En quoi on perd plus de droits avec un soft sous GPL qu'un soft sous BSD ?
        
        ??? On parlait de SQLite, qui est en "domaine public".
        Personnellement je me sens plus à l'aise de contribuer à des projets sous GPL que sous BSD, donc je crains que tu aies mal compris mon message précédent...
        
        D'ailleurs quand tu contribue à un projet GPL mené par une boite on te demande assez souvent de donner tous tes droits
        
        C'est le genre de choses que je n'accepterais pas ; quitte à ne pas contribuer, sauf pour de petits patchs sans importance.
        
        [^]Re: Pub
        
        Posté par Matthieu Moy (page perso, ) le 21/06/2004 à 14:23. (lien). Évalué à 3.
        > > D'ailleurs quand tu contribue à un projet GPL mené par une boite on te demande assez souvent de donner tous tes droits
        
        > C'est le genre de choses que je n'accepterais pas ; quitte à ne pas contribuer, sauf pour de petits patchs sans importance.
        
        Donc, tu ne contribueras pas au projet GNU (Qui demande le fameux "copyright assignment" pour la plupart de ses logiciels)...
        
        ?
        
        [^]Re: Pub
        
        Posté par Antoine () le 23/06/2004 à 13:25. (lien). Évalué à 2.
        Donc, tu ne contribueras pas au projet GNU (Qui demande le fameux "copyright assignment" pour la plupart de ses logiciels)...
        
        Exactement.
        Nonobstant, d'ailleurs, le fait que ce "copyright assignment" est parfaitement illégal en droit français.
    - [+] [^]Re: Pub
      
      Posté par zerchove () le 21/06/2004 à 08:21. (lien). Évalué à -1.
      oh les intaigraistes faudrait voir à laisser les gens libres un peu. Si le gars a envie de faire du domaine public, laisser le faire merde !
      
      ca commence a me gonfler les ayatollahs !

revenons sur terre

Posté par Antoine () le 19/06/2004 à 15:49. (lien). Évalué à 20.

SQLite est un moteur libre de base de données relationnelles aux possibilités fantastiques. Disons en deux mots qu'il a tout d'un grand,

Bémol. La limitation fondamentale de SQLite est son modèle de verrouillage rudimentaire, même comparé à MySQL. En effet, toute requête en écriture et même toute transaction ouverte sur la base verrouille toute la base de façon exclusive.

« Multiple processes can have the same database open at the same time. Multiple processes can be doing a SELECT at the same time. But only one process can be making changes to the database at once.
[...]
Locking in SQLite is very course-grained. SQLite locks the entire database. »
http://sqlite.org/faq.html#q7(...)

Autre point notable :

« An attempt to execute COMMIT might result in an SQLITE_BUSY return code. This indicates that another thread or process had a read lock on the database that prevented the database from being updated. When COMMIT fails in this way, the transaction remains active and the COMMIT can be retried later after the reader has had a chance to clear. »
http://sqlite.org/lang.html#transaction(...)

[^]Re: revenons sur terre

Posté par Moun's (page perso, ) le 19/06/2004 à 17:31. (lien). Évalué à 8.
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é.
- [^]Re: revenons sur terre
  
  Posté par nicodache () le 19/06/2004 à 19:48. (lien). Évalué à 3.
  pour le dernier point :
  tu oublies pas qu'il existe des "shared lock", en plus des "exclusive lock" ?
  
  (le lock en lecture sert simplement à éviter qu'un gars qui veuille modifier l'information puisse le faire directement, sans que les lecteurs soient informés... si il constate un shared lock, il doit (théoriquement) attendre qu'ils n'y en ait plus avant de poser un xlock pour modifier...
  
  in mon cours de base de donnée, qu'il m'a l'air juste quand même
  
  --
  Gougueul bombons ensemble :)
  - [^]Re: revenons sur terre
    
    Posté par Moun's (page perso, ) le 19/06/2004 à 20:05. (lien). Évalué à 4.
    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.
    - [^]Re: revenons sur terre
      
      Posté par Cedric Cellier (page perso, ) le 28/06/2004 à 16:57. (lien). Évalué à 1.
      Pas bien compris. Tu peut filer une source plus détaillées de comment un "copy on write" peut améliorer ou rendre inutile (pas bien co;pris ton propos) les locks, et rendre le dbms plus véloce ? J'ai fait une rapide recherche sur google et je vois pas...
- [^]Re: revenons sur terre
  
  Posté par Cedric Cellier (page perso, ) le 28/06/2004 à 16:43. (lien). Évalué à 1.
  - Qu'appelles tu une "fermeture transitive" ?
  
  - Qu'appelles tu la "profondeur" d'une table ? ("mettre un lock sur les tables concernés jusqu'à une certaine profondeur")
  
  - "mettre des versions de tuples" : tu parles des log des transactions par le DBMS ?
  
  - "le lock en lecture ca devrait etre breveté" : pourquoi au juste ?

[^]Nan, je plane toujours comme le Big Lebowski !!

Posté par bobert () le 19/06/2004 à 23:35. (lien). Évalué à 4.
Les extraits que tu donnes décrivent le comportement des versions 2.x de SQLite. Pour la version 3.0, cf. mon résumé, ou:

SQLite version 3.0 allows one process to begin writing the database while other processes continue to read. The writer must still obtain an exclusive lock on the database for a brief interval in order to commit its changes, but the exclusive lock is no longer required for the entire write operation. A more detailed [1] report on the locking behavior of SQLite version 3.0 is available separately.

[1] File Locking And Concurrency In SQLite Version 3
http://www.sqlite.org/lockingv3.html(...)

Voir aussi les deux extensions client-serveur que j'ai citées.

Bref, pas de quoi "revenir sur terre", comme tu dis si gentiment.

[^]Oui, mais... [workaround]

Posté par Cali_Mero () le 20/06/2004 à 00:35. (lien). Évalué à 6.
Bémol. La limitation fondamentale de SQLite est son modèle de verrouillage rudimentaire, même comparé à MySQL. En effet, toute requête en écriture et même toute transaction ouverte sur la base verrouille toute la base de façon exclusive.

Bémol sur ton bémol : si tu lis un peu plus loin, tu verras qu'une solution est proposée pour pouvoir verouiller sur des tables : stocker une table par base (donc par fichier) et attacher les bases entre elles pour que le SGBD les voie comme une base unique :

A limited form of table-level locking is now also available in SQLite. If each table is stored in a separate database file, those separate files can be attached to the main database (using the ATTACH command) and the combined databases will function as one. But locks will only be acquired on individual files as needed. So if you redefine "database" to mean two or more database files, then it is entirely possible for two processes to be writing to the same database at the same time. To further support this capability, commits of transactions involving two or more ATTACHed database are now atomic.

c'est sûr, c'est quand même assez contraignant...

L'idéal serait, je pense, de pouvoir spécifier le mode de stockage des tables lors de la création de la base (dans un fichier unique pour toutes les tables, ou dans un répertoire unique avec des fichiers distincts par table). Et là on aurait à moindres frais un verouillage au niveau de la table...

Je vais envoyer un e-mail au mainteneur pour lui proposer l'idée.

--
#define MAGIC 0xdefaced /* I should've patented this number -cliph */
- [^]Re: Oui, mais... [workaround]
  
  Posté par Antoine () le 20/06/2004 à 09:49. (lien). Évalué à 1.
  L'idéal serait, je pense, de pouvoir spécifier le mode de stockage des tables lors de la création de la base (dans un fichier unique pour toutes les tables, ou dans un répertoire unique avec des fichiers distincts par table). Et là on aurait à moindres frais un verouillage au niveau de la table...
  
  On va finir par réinventer MySQL :)
  - [^]Re: Oui, mais... [workaround]
    
    Posté par Cali_Mero () le 20/06/2004 à 11:39. (lien). Évalué à 2.
    Pffff, c'est limite du mauvais esprit ca :) Il faut prendre les bonnes choses là ou elles sont, et même avec ce genre de fonctionnalités, SQLite resterait beaucoup moins lourd que MySQL et garderait ses qualités parfaitement adaptées à l'embarqué.
    
    Blague à part, tous les SGBD font face aux mêmes problèmes (le stockage et la gestion d'accès concurrents) avec les mêmes moyens (un système de fichiers X ou Y). Il est normal qu'on arrive parfois, voire souvent, aux mêmes solutions, non ?
    
    --
    #define MAGIC 0xdefaced /* I should've patented this number -cliph */
  - [^]Re: Oui, mais... [workaround]
    
    Posté par Christophe Renard (page perso, ) le 20/06/2004 à 14:25. (lien). Évalué à 2.
    Sans vouloir faire de mauvais esprit, j'ai pas a me demander comment est foutu la table en dessous pour faire des jointures multi tables avec SQLite, avec MySQL, bonjour les suprises .....
    
    Bref, y'a peut etre moins de gadgets sur SQLLite mais au moins y'a du SQL ....
    
    j'ai trollé, ca y'est j'ai trollé, c'est plus fort que moi ...

explosion du trokilometre

Posté par Moun's (page perso, ) le 19/06/2004 à 15:53. (lien). Évalué à 4.

"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.

A chaque probleme sa solution.

[^]Re: explosion du trokilometre

Posté par bobert () le 19/06/2004 à 22:50. (lien). Évalué à 14.
donc, si c'est si simple

Bien sûr que ça n'est pas aussi simple, j'ai volontairement grossi le trait mais tout ça reste valable pour l'écrasante majorité des applications présentes sur un poste de bureau sous Linux.

Mon discours s'adressait aux développeurs de logiciels de tous les jours, de clients RSS, de lecteurs de news, de générateurs d'albums photo, de montage vidéo, de tableurs, etc. Pour tous ces usages l'emploi de SQLite pour la gestion de la persistance de ses données est très pertinent, je le maintiens.

Inversement, je veux bien que tu me cites une seule application d'une distribution Mandrake (au hasard) qui ait potentiellement affaire à 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... Honnêtement, c'est un peu pousser mémé dans les orties, non ?

le relationnel n'est pas une panacée, et ces 5 questions expose certains points faibles theoriques et pratiques du model

Ouais mais il s'agit pas de discuter de théorie et des faiblesses du modèle relationnel. Les utilisateurs de centaines de milliers d'applications client-serveur se disent pas tous les jours "ah merde, mes données sont stockées dans un SGBD relationnel, dont le modèle a des points faibles, quelle angoisse !!"

Mon propos était de proposer la puissance et la souplesse d'un SGBDR embarqué pour gérer les données d'une bête application autonome de tous les jours. Grâce à SQLite ça n'est pas réservé au client-serveur !

La question qui mérite d'être posée, c'est, plutôt que de réinventer la roue, un format de stockage de données, du code pour assurer la lecture / l'écriture / le traitement de ces données, pourquoi ne pas utiliser SQLite ? Pour les types d'applications que j'ai citées, on a tout à y gagner.

Et puisque tu sembles si bien connaître le modèle relationnel, pourquoi ne pas m'aider à défendre ce point de vue pour ce genre d'applications ?

Tu veux nourrir le troll ou lancer un débat constructif ?
- [^]Re: explosion du trokilometre
  
  Posté par Antoine () le 19/06/2004 à 23:19. (lien). Évalué à 3.
  La question qui mérite d'être posée, c'est, plutôt que de réinventer la roue
  
  Beaucoup d'applications ne réinventent pas la roue, elles utilisent des backends de stockage fournis par la distribution tels que Berkeley DB. Je ne sais pas trop ce qu'ils valent (l'API est probablement rudimentaire) mais le libre n'a pas attendu SQLite pour utiliser des backends fédérateurs.
  - [^]Re: explosion du trokilometre
    
    Posté par 007 () le 20/06/2004 à 00:12. (lien). Évalué à 2.
    > Berkeley DB.
    
    Ya aussi metakit :
    http://www.equi4.com/metakit.html(...)
    
    C'est peut-être l'occasion de faire une news avec "fantastique" "comparable à Oracle met en plus rapide" etc...
    
    Pour info Berkeley DB est le backend de rpm, evolution et subversion. J'en oublier évidement beaucoup beaucoup beaucoup.
    - [^]Re: explosion du trokilometre
      
      Posté par lorill (page perso, ) le 20/06/2004 à 08:43. (lien). Évalué à 1.
      openldap déja, ca me semble au moins aussi important que rpm ;)
- [^]Re: explosion du trokilometre
  
  Posté par Guillaume Laurent (page perso, ) le 20/06/2004 à 07:49. (lien). Évalué à 4.
  <<Mon discours s'adressait aux développeurs de logiciels de tous les jours, de clients RSS, de lecteurs de news, de générateurs d'albums photo, de montage vidéo, de tableurs, etc. Pour tous ces usages l'emploi de SQLite pour la gestion de la persistance de ses données est très pertinent, je le maintiens.>>
  
  Faut pas pousser non plus, pour tous les exemples que tu cites, des formats de fichiers textes tout simple suffisent largement. L'utilisation d'une DB, quelle qu'elle soit, ne se justifie que si tu as vraiment un gros tas de données à acceder rapidement. Pour un truc comme spamprobe par exemple, ça se justifie. Pour un lecteur news, un client RSS, ou un gestionaire d'album photo, c'est de l'over-engineering de débutant.
  - [^]Re: explosion du trokilometre
    
    Posté par bobert () le 20/06/2004 à 09:17. (lien). Évalué à 8.
    Pour un lecteur news, un client RSS, ou un gestionaire d'album photo, c'est de l'over-engineering de débutant.
    
    Débutant... hum... c'est pas la prétention qui t'étouffe... mais je ferai rien pour te contredire, si tu as besoin de te persuader que tu as la plus grosse ou fait plusieurs projets que quelqu'un dont tu ne connais rien.
    
    Alors prenons simplement l'exemple d'un lecteur de news, ok ? Quel est le lecteur de news le plus riche ou un des plus aboutis sous linux ? Pan [1].
    Les développeurs principaux, Chris Kerr et Duncan, ont commencé comme tout le monde par utiliser des formats de stockage "maison" dans de simples fichiers, pour toutes les données, relatives aux serveurs de news, aux liste de groupes, aux listes de groupes abonnés, aux listes d'en-têtes, aux corps de messages. Mais ils sont arrivés aux limites de ce mode de stockage, et sont précisément en train de tout réécrire...en utilisant SQLite.
    
    Tiens, je te laisse leur adresse, histoire que tu ailles aussi les traiter de débutants:
    
    Duncan <1i5t5 dot duncan at cox dot net>
    Charles Kerr <charles at rebelbase dot com>
    
    [1] http://pan.rebelbase.com/(...)
    - [^]Re: explosion du trokilometre
      
      Posté par Guillaume Laurent (page perso, ) le 20/06/2004 à 14:19. (lien). Évalué à 0.
      Si ta seule caution pour l'utilisation de SQLLite, ce sont deux mecs qui, en 2004, continuent de développer un N-ieme lecteur de news en C pseudo-objet, franchement...
      
      Bon, pour être clair :
      - c'est toi qui dit que Pan est le meilleur newsreader sous Linux, y en aura plein pour pas être d'accord (à lire la feature-list y a pleins de choses que gnus sait faire et pas lui, par exemple).
      
      - passer des lustres à développer du code sous Linux, même du code très utilisé, ne garanti rien quant à tes capacités réelles de codeur et designer. Développer du code open source, c'est une forme de dév très protégée du réel : tu fais ce que tu veux, y a très peu de conséquences parce que le plus souvent il n'y a pas grand chose en jeu (c'est pas le cas d'un truc comme Apache ou le kernel linux, mais pour Pan ça l'est clairement).
      
      - il arrive très fréquemment qu'un développeur découvre un "nouveau jouet" et veuille absolument l'utiliser, même si ça n'est pas justifié, et même si ça oblige à "tout re-écrire". Surtout si ça oblige à tout re-écrire, en fait :-). Ça arrive même chez les gars expérimentés, c'est un piège archi-classique.
      
      En plus dans cet exemple précis, la probabilité que leur code C soit devenu tellement spaghetti qu'ils n'arrrivent plus à l'etendre ou le maintenir et non-negligeable.
      
      Après, y a pas que moi qui trouve que c'est de l'over-engineering, y a lui aussi :
      
      http://www.jwz.org/doc/mailsum.html(...)
      - [^]Re: explosion du trokilometre
        
        Posté par bobert () le 20/06/2004 à 16:07. (lien). Évalué à 3.
        deux mecs qui, en 2004, continuent de développer un N-ieme lecteur de news en C pseudo-objet, franchement...
        
        Non mais je rêve...
        À part les Jacky et leur bagnole, je vois pas avec quoi comparer une telle arrogance et une telle mauvaise foi...
        Donc les développeurs de Gnome, de Pan, etc, ne valent rien, ah bon. Heureusement qu'on a encore des vrais mecs comme toi pour coder en C++, c'est vrai.
        
        c'est toi qui dit que Pan est le meilleur newsreader sous Linux
        
        C'est certainement un des plus riches ; peut-être un des plus populaires ; ça n'est pas moi qui le dis, c'est Freshmeat:
        http://freshmeat.net/browse/39/?filter=&orderby=rating_DESC(...)
        
        la probabilité que leur code C soit devenu tellement spaghetti qu'ils n'arrrivent plus à l'etendre ou le maintenir et non-negligeable.
        
        Ben tu vois, la meilleure façon de voir que ça n'est pas le cas, au lieu de faire des suppositions gratuites, c'est de regarder le code source de Pan. Vas-y, te gêne pas pour leur donner des conseils. Mais peut-être ne t'abaisses-tu pas à regarder du "C pseudo-objet"...
        
        Après, y a pas que moi qui trouve que c'est de l'over-engineering, y a lui aussi [lien vers une discussion sur le stockage des mails]
        
        Ton lien ne concerne pas du tout la problématique des lecteurs de news, mais l'indexation d'e-mails ; c'est absolument en-dehors du contexte.
        
        Un lecteur de news tel que Pan, ça ne fait pas que permettre d'écrire et de scorer des messages. Il se doit de
        
        - gérer des connexions multiples à des serveurs multiples
        - stocker / afficher des attachements binaires, les décoder en reconnaissant les formats d'encodages les plus récents (yenc par exemple)
        - repérer dans plusieurs messages des dizaines ou des centaines d'attachements binaires qui sont autant de parties d'un binaire unique (fichier ogg, archive rar, etc), et proposer un affichage & un traitement homogène de ces sous-parties
        - reconnaître que plusieurs centaines ou milliers de messages portent un attachement binaire qui est incomplet
        - tenir la volumétrie de certains newsgroups, sur certains serveurs, qui peuvent contenir plus d'un million de messages
        
        L'utilisation de SQLite ouvrirait la voie à de nouvelles fonctionnalités très utiles pour beaucoup d'utilisateurs:
        - gérer de manière unique des messages postés dans plusieurs groupes de discussion ; si la RFC prévoit un identifiant unique pour chaque message, dans la pratique les serveurs n'en tiennent pas compte, i.e. un client de news ne peut pas la plupart du temps demander à un serveur de récupérer le message ayant tel identifiant
        - gérer plusieurs serveurs de news de manière transparente pour l'utilisateur ; bien souvent l'abonnement à un provider de news donne accès à un certain nombre de serveurs aux caractéristiques différentes (bande passante maximum, nombre de connexions simultanées, volume maximum de téléchargement autorisé par jour, rétention des messages de 5, 10, 15 jours, disponibilité ou non de tel ou tel groupe de discussion). L'idée serait donc de laisser l'utilisateur récupérer les messages de son choix, sans qu'il ait manuellement à gérer le choix des serveurs / groupes de discussion
        
        [+] [^]Re: explosion du trokilometre
        
        Posté par Guillaume Laurent (page perso, ) le 20/06/2004 à 22:05. (lien). Évalué à -2.
        > À part les Jacky et leur bagnole, je vois pas avec quoi comparer une telle arrogance et une telle mauvaise foi...
        
        Oh la barbe, arrête de prendre des airs de pucelle effarouchée parce que j'ai une opinion tranchée sur Gnome. Oui, développer sous Gnome n'est clairement pas un signe de compétence technique. Y a des mecs très pointus qui bossent sous Gnome, mais avec des oeillères taille XXL. Et hors des technos Gnome, ils sont aux fraises. Les autres se cassent ailleurs (pourquoi crois-tu que Miguel s'est jeté dans Mono ?).
        
        > Mais peut-être ne t'abaisses-tu pas à regarder du "C pseudo-objet"...
        
        'Been here, done that, long ago. Maintenant, j'ai un peu autre chose à foutre.
        
        > Ton lien ne concerne pas du tout la problématique des lecteurs de news, mais l'indexation d'e-mails
        
        Euh, tu le fais exprès là ? La problèmatique n'est pas juste celle du lecteur de news, elle est de savoir si il est pertinent d'employer une DB dans la plupart des softs desktop, comme tu l'affirmes. Ce lien est un bon exemple qui te prouve le contraire. J'ose espérer que tu n'aura pas la mauvaise foi de maintenir qu'il n'a rien à voir avec la discussion en cours.
        
        > L'utilisation de SQLite ouvrirait la voie à de nouvelles fonctionnalités très utiles pour beaucoup d'utilisateurs: [...]
        
        Absolument rien de ce que tu listes ne nécéssite une DB, ça serait prendre un marteau pour casser des oeufs. Une DB c'est quand tu veux faire très rapidement des requêtes complexes sur un très gros volume de données. En dessous de 50Mb, c'est pas un très gros volume de données, grep fait l'affaire.
        
        Par ailleurs je ne pense pas que les "nouvelles fonctionalités" que tu cites soient d'une quelconque utilité, mais bon, c'est un autre débat.
  - [^]Re: explosion du trokilometre
    
    Posté par Christophe Renard (page perso, ) le 20/06/2004 à 14:32. (lien). Évalué à 4.
    Le probleme surgit quand avec ton format de fichier tu veux comparer deux "bidules" qu'a priori tu n'avais pas pensé à correller et qui, justement se trouvent coincés chacun au bout d'une joli structure arborescente.
    
    L'avantage de SQLite, c'est que tu vas resoudre pas mal de problemes avec de "simples" requetes SQL et passer moins de temps sur les problemes de tris, retris, croisement et sauvegardes de fichiers...
    
    Combien de temps perdu a reecrire des sauvegardes/chargements de fichiers (buggués bien sur) ?
    Combien de quicksort ont été 100 fois réécris ?
    
    Quand tu consideres qu'en plus SQLLite est plutot compact et rapide et fait des fichiers d'une taille assez raisonnable, ca le place tout betement comme un excellent outil dans la panoplie du programmeur, en particulier dans les applis interactives ou on a pas forcement envie d'imposer un backend SGBD à l'utilisateur.
    - [^]Re: explosion du trokilometre
      
      Posté par Guillaume Laurent (page perso, ) le 20/06/2004 à 15:01. (lien). Évalué à 3.
      SQLLite va surement t'aider a résoudre pleins de problèmes, il va aussi t'en créer pleins d'autres. Et parmi les pbs qu'SQLLite va résoudre, combien se posent en pratique dans une appli genre un newsreader ou un lecteur RSS, et sont vraiment si dur que ça à résoudre autrement ?
      
      Lire et écrire un fichier n'est pas particulièrement compliqué, et pour le tri je pense qu'il est plus difficile de trouver un langage qui ne dispose pas d'un algo de tri en standard qu'un qui en a un. Même la lib standard C implémente quicksort.
      
      Oui, SQLLite et surement un outil très utile à avoir. Mais pas aussi souvent que bobert se l'imagine, loin de là.
      - [^]Re: explosion du trokilometre
        
        Posté par Christophe Renard (page perso, ) le 20/06/2004 à 15:30. (lien). Évalué à 3.
        Je n'ai écrit ni newsreader ni client RSS, mais si j'imagine un usage un peut intensif du client RSS, ca va me permettre de faire des corrélations entre sources mais aussi de proposer à l'utilisateur de chercher dedans de façon tres evoluée.
        
        Pour un client mail je vois tout de suite l'usage, j'ai personnellement plus de 2Gb de mail (je ne jette rien depuis 1997) et j'ai écris mon propre petit outil d'indexation (avec SQLLite il se trouve) pour chercher dedans plus simplement qu'avec aucun client mail que je connaisse. Rien de bien tordu mais ca marche et vite (le fichier de reference fait environ 15Mb).
        
        "Lire et écrire un fichier n'est pas particulièrement compliqué, "; Il n'y qu'a voir avec quelle régularité un bon nombre d'applis corrompent leurs données, ou deviennent incapable de relire leur formats de fichiers entre deux versions. Faire une paire de routines de lecture écriture de fichier n'est pas bien compliqué, mais définir un bon format de fichier, le faire vivre et évoluer, ca n'a rien de simple. La dessus ajoute le fait que pour debugguer le tout il faudra sans doute ecrire ses propres outils d'exploration, génération d'exemples, mise à jour ..... bref ca devient vite compliqué.
        Bien sur avec un format pur texte c'est plus simple, à condition d'avoir pensé au départ au multilinguisme, et à encoder les données purement binaire (son, images, échantillions de mesures) avant de les écrire (et évidemment faire attention à l'encodage entre librairies : chaines UTF-XX, ASCII, 8859-xx ?).
        Au final si tant de monde adopte le XML et les librairies de lecture/écriture de ce format ca n'est pas sans bonnes raisons.
        
        Pour ce qui est des fonctions de tri, oui il y'en a partout, mais il faut a chaque fois recoder les fonctions de comparaison, c'est à mes yeux plus complexe (surtout à maintenir) qu'une syntaxe dédiée à cet usage telle celle du SQL. Sans compter que moult programmeurs préferent réimplementer leur propres fonctions plutot que tenter d'utiliser les fonctions évoluées des bibliothèques (voir l'usage de la librairie standard C++ hors du cercle des experts de la norme).
        
        SQLLite fournit un stockage relationnel, et les outils qui vont avec, je vois peut de problèmes provoqués par cela (mais je ne vais pas essayer de faire rentrer dedans des données qui ne s'y pretent pas).
        
        La news est un chouia enthousiaste, mais je m'y joins pour inviter chaque programmeur qui ne soit pas trop "à cheval" sur la GPL à jeter un oeil à SQLite parceque c'est bien fichu et vraiment à connaitre pour LA fois ou ce sera peut être la réponse au problème du jour.
        
        [^]Re: explosion du trokilometre
        
        Posté par Guillaume Laurent (page perso, ) le 20/06/2004 à 22:29. (lien). Évalué à 1.
        <<si j'imagine un usage un peut intensif du client RSS, ca va me permettre de faire des corrélations entre sources mais aussi de proposer à l'utilisateur de chercher dedans de façon tres evoluée.>>
        
        Quelles corrélations entre sources ? Peux-tu me citer un exemple, je ne vois pas ce que tu veux dire. Quant à faire des recherches dessus, y a déjà google... Et même, tu vas vraiment avoir besoin de plus qu'une simple recherche de mots clés ou de regexp, éventuellement triée sur la date ? Est-il vraiment utile d'ajouter une DB juste pour ça ?
        
        <<Pour un client mail je vois tout de suite l'usage, j'ai personnellement plus de 2Gb de mail [...]>>
        
        Tu n'es pas un cas typique, mais un de mes potes est exactement comme toi, sauf que lui c'est depuis le début des années 90 je crois (je ne sais plus quand exactement). Tout son mail est au format mh, et je crois me souvenir qu'il indexe avec glimpse. OK, à ce niveau là une DB est bienvenue. Mais sur les 20Mb de mail (sans compter les attachements, bien sur) qu'a l'utilisateur moyen, je maintiens que ça n'en vaut pas la peine. Si tu vises plus large, à ce moment là tu fais un outil de recherche généralisé pour tout tes fichiers tant qu'a faire, pas juste ton mail. Et tu ré-invente longhorn ou google-sur-pc :-).
        
        <<Il n'y qu'a voir avec quelle régularité un bon nombre d'applis corrompent leurs données, ou deviennent incapable de relire leur formats de fichiers entre deux versions.>>
        
        Ouais, comme les DBs par exemple. La corruption de données ça arrive forcément un jour ou l'autre, la seule question c'est comment limiter le niveau d'emmerdement. Et là une DB est une mauvaise réponse, alors qu'un bon gros format texte bien neuneu, c'est pas trop dur d'y retrouver ses petits. Quand à l'évolution d'un format d'une version à l'autre, ben c'est au dev de se dermerder pour être backward compatible si il ne veut pas trop faire chier ses utilisateurs. Là aussi une DB ne va pas t'aider, si c'est pas le format de la DB qui change, c'est le format de tes datas dans la DB...
        
        Après oui, faire un format de données c'est pas si simple, mais il y en a tellement d'existants que c'est bien le diable si tu ne peux pas trouver ton bonheur quelque part.
        
        <<Sans compter que moult programmeurs préferent réimplementer leur propres fonctions plutot que tenter d'utiliser les fonctions évoluées des bibliothèques>>
        
        Y a des clowns partout. Mais je n'ai jamais travaillé pour une boite qui aurait accepté qu'un dev perde du temps à recoder quicksort, ni vu un dev assez bête pour le faire, quelque soit le langage.
        
        <<jeter un oeil à SQLite parceque c'est bien fichu et vraiment à connaitre pour LA fois ou ce sera peut être la réponse au problème du jour.>>
        
        Entièrement d'accord. Là ou j'objecte, c'est quand on me dit que c'est tout le temps la réponse, ou presque.
        
        [^]Re: explosion du trokilometre
        
        Posté par Christophe Renard (page perso, ) le 21/06/2004 à 11:47. (lien). Évalué à 5.
        J'ai un exemple simple, j'ai un client qui fait de la veille pour lequel on etudie un outil.
        Il est intéressé à stocker les feeds d'info(Reuter par exemple) auquels il est abonné et quelques feeds RSS et des listes de brevets.
        Il veut pouvoir taper dedans pour sortir: les articles écrits par le professeur bidule ou les entrées qui mentionnent le labo de bidulotique entre le 42 janvier et 54 fevrier, ou les articles donc les intervenants sont mentionnés dans des publications comportant le mot clé machinosetriphasée...
        C'est un besoin qui dépasse le simple client RSS, mais avec la généralisation du format je ne serai pas surpris de voir pas mal de monde thésauriser les feeds pour retrouver des articles.
        C'est sur on peut tout stocker en XML ou un format texte, mais pour de la recherche structurée c'est pas l'extase.
        
        Pour le mail, il me semble que la popularité de l'annonce de GMail est la preuve que mon genre de mailomanie n'est pas si exceptionnel.
        D'expérience, ces derniers mois, 20Mo c'est plutot le courrier de la semaine d'un utilisateur pas la totalité de ses archives de courriel.
        En ce qui me concerne, j'indexe toutes les nuits le mail en tenant compte des infos structurées : FROM, TO, SUBJECT, MAIL-ID, MIME-PARTS ... Du coup je peux interroger la base pour sortir les emails avec un attachement en .PPT envoyés par machin (pour retrouver toutes les bonnes blagues qu'on m'a envoyé).
        En cherchant le texte brut je perds la structuration. II y'a bien des outils pour chercher dans les mailbox mais c'est long et lent surtout quand tu recherches sur moult fichiers.
        Bref mon bidule est un petit outil en ligne de commande d'un intéret tellement insignifiant que je suis le seul utilisateur, mais je m'en sers trés régulièrement et ca marche de façon simple, pas besoin de Google ou WinFS (ou BeFS) et c'est substanciellement plus rapide que la recherche depuis un client mail. Utiliser SQLite m'a permis de le faire en quelques heures de boulot au lieu de quelques jours si j'avais du coder les détails.
        
        Pour la corruption de données, je pense surtout a celles dues à des bugs ou des problèmes de régression. J'en ai rencontré pas mal en particulier dans des softs "sur mesure" réalisés par des SSII aux contraintes de temps trop serrées mais aussi dans des grandes applications, censées être fiables.
        
        L'idée de se baser sur une lib deja existante permet de déporter le problême : plus de monde qui rencontre les bugs implique plus de chance que ceux -ci soient corrigés sans avoir à le faire soit même, qui plus est qui dit upgrade du format dit outils de migration, ne pas avoir à les réaliser est un sacré gain de temps.
        Si ce format est une BDD, dans pas mal de cas ca me parait avantageux.
        Evidemment ca ne réponds pas à tous les besoins, mais même pour des quantités d'info moyennes l'économie de code complexe (recherches, tris, arbres, skip-list ou table de hashage) est une réduction considérable de risque de bugs. Je ne sais pas pour toi, mais personnellement, je trouve un rapport direct entre la quantité de code que j'écris et le nombre de bugs.
        
        Pour les clowns, j'ai deja récupéré des projets sous-traités à la petite semaine, développés par des gars reconvertis informaticiens en 6 mois et qui avaient eu un cours de C with class pompeusement nommé C++ et qui n'avaient jamais entendu parler de namespace et encore moins de containeurs de la lib standard.
        Alors évidemment, #include <algorithm> et utiliser des iterateurs c'est semble plus compliqué que de magouiller un truc bizarre avec une double liste chainée maison ( en plus une liste utilisée pour des pour des accés aléatoires) dans de telles conditions.
        Bref du code moisi, c'est fréquent, et quand on utilise une librairie ad-hoc pour le boulot ca laisse moins d'opportunité de se tirer dans les pieds (enfin ca requiers 3 notions de SQL qui ne sont pas données à tous le monde mais tout de même ...).
        
        Enfin au final je pense que nous sommes d'accord, ca n'est pas une solution universelle mais ca peut servir.
        
        [^]Re: explosion du trokilometre
        
        Posté par Guillaume Laurent (page perso, ) le 21/06/2004 à 18:00. (lien). Évalué à 2.
        <<Enfin au final je pense que nous sommes d'accord, ca n'est pas une solution universelle mais ca peut servir.>>
        
        Oui, les cas que tu cites sont des cas pour lesquels j'utiliserais probablement aussi une DB. Ceci dit si ca commence a vraiment prendre de l'ampleur, et que tu fais ca pour un client, il y a de bonnes chances pour qu'il ait déjà son install Oracle et qu'il te demande de t'y integrer :-).
        
        [^]Re: explosion du trokilometre
        
        Posté par Christophe Renard (page perso, ) le 22/06/2004 à 00:32. (lien). Évalué à 2.
        Oracle est trop cher pour la plupart des PME de moins de 50 employés (comme mes clients) .
        
        Postgresql pourrait faire l'affaire, mais pas de bol plein d'employés travaillent sur des portables sous Winxx dans leur coin.
        
        SQLLite avec quelques fonctions de synchro "custom", ca marche bien.
  - [^]Re: explosion du trokilometre
    
    Posté par thaodalf () le 21/06/2004 à 11:13. (lien). Évalué à 1.
    pour un gestionnaire de photo l'utilisation de sqlite peut être tres interresant, histoire de garder des meta données par exemple.
    
    je suis moi meme entrain de paser une appli qui utilisait des fichiers xml en 1 fichier sqlite, ca simplifie le projet !
    - [^]Re: explosion du trokilometre
      
      Posté par Guillaume Laurent (page perso, ) le 21/06/2004 à 18:45. (lien). Évalué à 1.
      Quand tu commences vraiment à avoir beaucoup de photos (disons quelques dizaines ou centaines de milliers, pas si rare avec les appareils numériques), pourquoi pas. Sinon, là encore un index texte tout con dans lequel tu vas dumper tes data exifs fera largement l'affaire. Note bien qu'on rentre très rarement des annotations manuelles, simplement parce que c'est trop lourd à faire. Longhorn a bien pigé ça en fournissant un mécanisme générique d'extraction des meta-datas en fonction du format du fichier.
      
      Mais bon, en fait dès que tu explores la question des DBs dans des applis, tu en arrives toujours a la même conclusion : pour que ça marche bien faut foutre la DB dans le filesystem :-). Comme ça tu as le meilleur des deux mondes : recherche évoluée sans effort de dev, fiabilité, pas de dépendence avec une lib exotique... C'est pas pour rien que BeOS ou Longhorn mettent cette idée en pratique.
      - [^]Re: explosion du trokilometre
        
        Posté par jmfayard () le 22/06/2004 à 12:19. (lien). Évalué à 2.
        Quand tu commences vraiment à avoir beaucoup de photos (disons quelques dizaines ou centaines de milliers, pas si rare avec les appareils numériques), pourquoi pas. Sinon, là encore un index texte tout con dans lequel tu vas dumper tes data exifs fera largement l'affaire. Note bien qu'on rentre très rarement des annotations manuelles, simplement parce que c'est trop lourd à faire
        
        ça dépend avec quelle application : http://ktown.kde.org/kimdaba/(...) ;-)
        (utilise un fichier texte (xml) tout con d'ailleurs, comme tu le préconises)
  - [+] [^]Re: explosion du trokilometre
    
    Posté par Alain Tésio (page perso, ) le 22/06/2004 à 17:50. (lien). Évalué à -1.
    N'importe quoi, si le programme devient un peu complexe, même s'il n'y a pas des volumes énormes, gérer le formatage (dans les deux sens) des fichiers de données devient vite lourd
- [^]Re: explosion du trokilometre
  
  Posté par Moun's (page perso, ) le 20/06/2004 à 11:09. (lien). Évalué à 3.
  tu as grossi les traits soit.
  
  "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: explosion du trokilometre
    
    Posté par B r u n o (page perso, ) le 20/06/2004 à 11:57. (lien). Évalué à 2.
    Il existe quoi comme solution pour stocker/interroger des arbres/graphes?
    
    Car c'est vrai que dans une application on y est souvent confronté, comme il y a casi-toujours un sgbdr utilisé on ne se pose pas la question et on stocke ca dans la base (par exemple pour gérer des profils de users avec des droits qui s'héritent, une représentation fonctionnelle d'une entreprise, une gestion de taches, de workflow, etc... )
    
    Pour stocker les arbres, je pensais jeter un oeil sur les bases xml. Un document xml étant un arbre, ca pourrait être pratique. D'autant plus que XPath permet des choses assez sympa... Comme toujours, il manque toujours du temps pour approfondir (j'ai une TODO list qui tient sur les 2 prochaines années je pense). Donc tes expériences ou qq pointeurs seraient les bienvenus.
    - [^]Re: explosion du trokilometre
      
      Posté par Moun's (page perso, ) le 20/06/2004 à 13:13. (lien). Évalué à 1.
      je bosse sur le sujet depuis plus de 10 ans.
      
      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 Volnai () le 20/06/2004 à 12:56. (lien). Évalué à 0.
    Tu as l'air de bien t'y connaitre dans toutes ces histoires de performance sur les graph, tu pourrais peut etre aussi leur proposer des solutions en plus de leur expliquer qu'ils se plantent ?
    - [^]Re: explosion du trokilometre
      
      Posté par Moun's (page perso, ) le 20/06/2004 à 13:22. (lien). Évalué à 0.
      je pense que ma reponse ici http://linuxfr.org/comments/434305,1.html(...) repond à ta question.
    - [^]Re: explosion du trokilometre
      
      Posté par Moun's (page perso, ) le 20/06/2004 à 13:37. (lien). Évalué à 0.
      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 ? ;)
  - [^]Re: explosion du trokilometre
    
    Posté par Christophe Renard (page perso, ) le 20/06/2004 à 14:43. (lien). Évalué à 3.
    Tu as indeniablement raison : on trouve des arbres et des graphes partout.
    
    Mais, tu admettras tout de meme que dire "rapport signal/bruit aux niveaux des tables tendant rapidement vers 0 ( un bon exemple est les 12 000 tables de SAP/V3 )" est de la mauvaise fois. SAP n'est pas une application simple ou rapidement concue. Pour modeliser ce que SAP tend à automatiser (soit à peut prés tout les proccessus d'une entreprise), il n'y sans doute pas de modele de représentation qui soit trivial, car le probleme est en soit (exagerement?) complexe.
    
    Si les SGBR ne sont évidemment pas une sorte de panaçée universelle, ils offrent une solution pratique dans pas mal de cas. En particuliers dans tous les cas, généralement peut intéressants sur le plan de la recherche actuelle, mais forts courant dans une utilisation courante de l'informatique : quand un probleme se decompose bien en entites/relations.
    
    Bref, il y'a malheureusement en informatique des modes et des cycles technologiques qui ne sont pas toujours rationnels, les meilleures solutions sont rarement pures (objet ou client/serveur ou relationnelles ou fonctionnelles ou centralisées ou scripts ou ....), même si le vendeur de chaque techno la vend comme telle.
    
    Il faut faire avec, mais ca n'empeche pas SQLite d'être un bon petit outil bien pratique à connaitre.
    - [^]Re: explosion du trokilometre
      
      Posté par Moun's (page perso, ) le 20/06/2004 à 15:20. (lien). Évalué à 2.
      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.
      - [^]Re: explosion du trokilometre
        
        Posté par Christophe Renard (page perso, ) le 21/06/2004 à 11:59. (lien). Évalué à 3.
        Le mapping Merise/relationnel est bien connu et couremment pratiqué.
        Bon de toute façon la popularité de Merise est en chute libre, ce qui n'est pas le cas des bases relationnelles.
        
        Pour une application de compta même analytique, certe beaucoup de tables sont vites requises (mais de l'ordre de la dizaine plutot que les 10aines de millier de SAP).
        
        Mon postulat est que dans le cadre d'une implémentation pratique avec les outils aujourd'hui couremment disponibles. Un SGBDR est un excellent outil, sans doute le meilleur dans la plupart des applis de gestion.
        
        Je ne trouve pas que les SGBDO apportent d'ameliorations substancielles dans ce genre de contextes.
        
        Et je ne connais pas d'outil permettant de modéliser une problématique en terme de graphes et de construire une appli autour.
        
        Je n'affirme pas qu'un moteur relationnel soit la panacée, mais il faut bien admettre que c'est une solution qui à énormément progressé depuis les années 80 (y compris par l'absorbtion de techniques exogènes au relationnel : cubes de données, systèmes de types extensibles, traitement du plein texte...(je ne parlerai pas des fonctions d'arbres d'Oracle) ) et dont les implémentations offrent un souplesse que peut d'outils alternatifs offrent.
        
        Enfin à peut de choses prét nous devons être du même avis.
        
        [^]Re: explosion du trokilometre
        
        Posté par Moun's (page perso, ) le 21/06/2004 à 13:27. (lien). Évalué à 1.
        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 .
        
        pour les graphes, ...
        
        [^]Re: explosion du trokilometre
        
        Posté par Christophe Renard (page perso, ) le 21/06/2004 à 13:58. (lien). Évalué à 2.
        Pour ce qui est d'UML, l'usage est plutot d'utiliser un stockage objet quand on modélise en objet (meme si ce stockage n'est qu'une couche de sérialisation par dessus un SGBDR). D'experience on rencontre d'ailleurs souvent des boucles avec des conditions complexes parcourant des listes d'objets pour faire des operations de reporting qui seraient triviales en attaquant directement la couche relationnelle.
        Ma conclusion : vive l'hybridation.
        
        Quand j'ai dis, malencontreusement "de l'odre de la dizaine", je pensais en fait "se compte en dizaines" comparé à la dizaine de milliers de tables d'un SAP.
        Par contre j'ai évoqué une compta et le problème que tu poses est celui d'un ERP ( gestion de stocks, de RH, des caisses ...). Je peux t'assurer que ce genre de fonction ne sont pas dans un soft de compta de base (elles font l'objet de fort couteux modules d'extension).
        Bref, comme je n'ai pas 3 mois devant moi et non plus qu'une connaissance correcte de la grande distrib je ne m'attaquerai pas à ton exemple.
        Mais si tu te referes à ma remarque plus haut tu noteras que je postule que justement la complexité est inhérente à ce genre de problème qui croise une multitude de facteurs et pas à leur representation relationnelle.
        
        Par contre je serai curieux (réellement, sans volonté polémique) de savoir comment ce genre de problème se résout en le modélisant par des graphes et quels outils tu peux utiliser pour passer du modèle à l'implémentation. Si c'est possible ca m'intéresse grandement.
        
        Si je ne m'abuse LDAP, XML sont des modéles d'arbres, pas de graphes(non dégénérés) ou justement on introduit des ID un peut artificiels pour representer les relations transversales.
        
        Dans les bases XMLnatives il y'a aussi Tamino de Software AG qui prétend à devenir pour le XML ce qu'Oracle est au relationnel.
        
        Pour les graphes ?
        
        [^]Re: explosion du trokilometre
        
        Posté par Moun's (page perso, ) le 21/06/2004 à 17:13. (lien). Évalué à 2.
        pour UML ... :)
        
        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 Moun's (page perso, ) le 21/06/2004 à 18:54. (lien). Évalué à 1.
        saloperie de html :|
        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

Firefox l'utilisera sans doute pour l'historique

Posté par Olivier Cahagne () le 19/06/2004 à 16:33. (lien). Évalué à 8.

Articles précédents : Logiciel

Liens connexes

Dépêche modérée par

Logiciel : Ça bouge du côté de SQLite !

Pub

[^]Re: Pub

[^]Re: Pub

[^]Re: Pub

[^]Re: Pub

[^]Re: Pub

[^]Re: Pub

[^]Re: Pub

[^]Re: Pub

[^]Re: Pub

[^]Re: Pub

[^]Troll

[^]Re: Troll

[^]Re: Troll

[^]Re: Pub

[^]Re: Pub

[^]Re: Pub

[^]Re: Pub

[^]Re: Pub

[^]Re: Pub

[^]Re: Pub

[^]Re: Pub

[^]Re: Pub

[+] [^]Re: Pub

revenons sur terre

[^]Re: revenons sur terre

[^]Re: revenons sur terre

[^]Re: revenons sur terre

[^]Re: revenons sur terre

[^]Re: revenons sur terre

[^]Nan, je plane toujours comme le Big Lebowski !!

[^]Oui, mais... [workaround]

[^]Re: Oui, mais... [workaround]

[^]Re: Oui, mais... [workaround]

[^]Re: Oui, mais... [workaround]

explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[+] [^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[+] [^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

[^]Re: explosion du trokilometre

Firefox l'utilisera sans doute pour l'historique