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. 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 !
Aller plus loin
- Le projet SQLite (143 clics)
- Changements apportés par la version 3.0 (50 clics)
- Un article sur SQLite publiée dans Linuxjournal (36 clics)
- Utilisez SQLite avec le langage de votre choix (124 clics)
- Liste non-exhaustive des projets utilisant SQLite (91 clics)
# Pub
Posté par ftp . Évalué à 10.
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 . Évalué à 10.
Il faudrait que plus de news soient aussi complètes !
[^] # Re: Pub
Posté par Guillaume Knispel . Évalué à 1.
[^] # Re: Pub
Posté par Pierre Jarillon (site web personnel) . Évalué à 8.
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 . Évalué à 10.
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 (site web personnel) . Évalué à 2.
« 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 . Évalué à 6.
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 (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 7.
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 . Évalué à 4.
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 . Évalué à 0.
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 . Évalué à 2.
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 . Évalué à 3.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 5.
- 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 . Évalué à 5.
« 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 . Évalué à 2.
[^] # Re: Pub
Posté par supergab . Évalué à 3.
[^] # Re: Pub
Posté par Antoine . Évalué à 2.
[^] # Re: Pub
Posté par Éric (site web personnel) . Évalué à 2.
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 . Évalué à 2.
??? 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 (site web personnel) . Évalué à 3.
> 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 . Évalué à 2.
Exactement.
Nonobstant, d'ailleurs, le fait que ce "copyright assignment" est parfaitement illégal en droit français.
[^] # Re: Pub
Posté par zerchove . Évalué à -1.
ca commence a me gonfler les ayatollahs !
# revenons sur terre
Posté par Antoine . Évalué à 10.
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 Mouns (site web personnel) . É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é.
[^] # Re: revenons sur terre
Posté par nicodache . Évalué à 3.
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
[^] # Re: revenons sur terre
Posté par Mouns (site web personnel) . É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 Cedric Cellier . Évalué à 1.
[^] # Re: revenons sur terre
Posté par Cedric Cellier . Évalué à 1.
- 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 . Évalué à 4.
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 . Évalué à 6.
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.
[^] # Re: Oui, mais... [workaround]
Posté par Antoine . Évalué à 1.
On va finir par réinventer MySQL :)
[^] # Re: Oui, mais... [workaround]
Posté par Cali_Mero . Évalué à 2.
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 ?
[^] # Re: Oui, mais... [workaround]
Posté par Christophe Renard . Évalué à 2.
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 Mouns (site web personnel) . É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.
[^] # Re: explosion du trokilometre
Posté par bobert . Évalué à 10.
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 . Évalué à 3.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 1.
[^] # Re: explosion du trokilometre
Posté par Guillaume Laurent (site web personnel) . Évalué à 4.
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 . Évalué à 8.
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 (site web personnel) . Évalué à 0.
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 . Évalué à 3.
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 (site web personnel) . Évalué à -2.
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 . Évalué à 4.
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 (site web personnel) . Évalué à 3.
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 . Évalué à 3.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 5.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 2.
ç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 . Évalué à -1.
[^] # Re: explosion du trokilometre
Posté par Mouns (site web personnel) . É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: explosion du trokilometre
Posté par B r u n o (site web personnel) . Évalué à 2.
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 Mouns (site web personnel) . É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 Volnai . Évalué à 0.
[^] # Re: explosion du trokilometre
Posté par Mouns (site web personnel) . Évalué à 0.
[^] # Re: explosion du trokilometre
Posté par Mouns (site web personnel) . Évalué à 0.
[^] # Re: explosion du trokilometre
Posté par Christophe Renard . Évalué à 3.
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 Mouns (site web personnel) . É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 Christophe Renard . Évalué à 3.
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 Mouns (site web personnel) . É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: explosion du trokilometre
Posté par Christophe Renard . Évalué à 2.
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 Mouns (site web personnel) . É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) . É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# Firefox l'utilisera sans doute pour l'historique
Posté par Olivier Cahagne . Évalué à 8.
http://bugzilla.mozilla.org/show_bug.cgi?id=245745(...)
à la place du système Mork:
http://bugzilla.mozilla.org/show_bug.cgi?id=241438(...)
PS: Cela aurait été sympa d'utiliser Sqlite du temps de Firebird... :)
# pfff
Posté par TImaniac (site web personnel) . Évalué à 4.
Et les documents XML c'est fait pour quoi ? C'est souvent tout aussi pertinent et beaucoup plus souple à utiliser et bien plus facilement transportable et bien meilleur question interopérabilité... Et parfois plus facile à utiliser avec certains outils de mapping relationnel/objet par exemple... Franchement faut arrêter de délirer, un SGBD peut être une bonne solution, mais c'est loin d'être pertinent dans toutes les applications. Voilà c'est mon avis sur cette publicité.
[^] # Re: pfff
Posté par scand1sk (site web personnel) . Évalué à 2.
[^] # Re: pfff
Posté par Vivi (site web personnel) . Évalué à 10.
Le XML c'est bien pour l'échange de donnée, l'interopérabilité entre applications, etc. Pour le stockage et les requêtes c'est complémtement inadapté.
SQLite c'est l'inverse: c'est trés bien pour les requêtes mais c'est pas fait pour l'interopérabilité: mauvais support de la concurrence (même si ça s'arrange), prévu pour être lié statiquement au programme, etc.
[^] # Re: pfff
Posté par TImaniac (site web personnel) . Évalué à 3.
Le XML c'est bien pour l'échange de donnée, l'interopérabilité entre applications, et
C'est ce que j'ai dis, donc dans certains cas c'est un bon format de stockage, je prendrais par exemple le format de OOo.
Pour le stockage et les requêtes c'est complémtement inadapté.
Voilà, c'est pour celà que j'ai dis que à chaque problème sa solution. (Mais bon, si je reprend l'exemple de OOo, c'est bien de stockage que l'on parle (même si je préfère parler de persistance), comme quoi c'est parfois adapté quand même :-p)
N'importe quoi, ça n'a rien à voir.
Je comprend pas, tu paraphrases mon post...
Enfin bon, on est d'accord sur le fond je pense, je souhaitais juste préciser qu'il y avait d'autres solutions, parfois plus pertinente que SQLite.
Mais dans la plupart des cas, un SGBD est nécessaire dès qu'on atteind une quantité importante de données à traiter et surtout dès qu'on a des accès concurrents, et là SQLite c'est pas du tout son truc... Donc pour moi SQLite n'a que très peu d'application pratique, excepté dans de petites applications qui préfèrent privilégier l'utilisation du langage SQL et un petit gain de vitesse à l'neregistrement des données plutôt que d'utiliser une solution interopérable, et qui force à bien structurer son application (obligation de faire une couche de persistance et un mapping XML/Objet, mais c'est tellement plus propre...)
Enfin chacun sa priorité...
[^] # Re: pfff
Posté par Vivi (site web personnel) . Évalué à 1.
Mais toutes les applications ne fonctionnent pas sur ce shéma. Exemple un truc genre juke-box (rhythmbox) ou un gestionnaire de sources (monotone utilise SQLite). Là il y a des données qui peuvent être assez grosses, qu'il faut pouvoir interroger assez rapidement et qu'on a pas envie de charger en mémoire.
[^] # Re: pfff
Posté par bobert . Évalué à 2.
Parfait, alors sur le fond on est d'accord. Je proposais simplement à tout développeur de regarder sérieusement SQLite, pas d'en faire sont Saint Graal.
Sur la forme de la réponse, classique sur linuxfr, qui consiste à balancer une réponse méprisante à son petit camarade et à réfléchir après, je te propose cette lecture enrichissante [1] qui discute entre autres des performances du traitement de données stockées sous forme relationnelle et sous forme de XML, juste histoire de se mettre d'accord sur ce dont on parle.
Méfie-toi, l'auteur est un ancien de chez Microsoft, donc c'est sûrement un autre gogo qui ne sait pas coder (ahem...)
[1] Joel Spolsky (2001) Back to Basics
http://www.joelonsoftware.com/articles/fog0000000319.html(...)
[^] # Re: pfff
Posté par TImaniac (site web personnel) . Évalué à 1.
Naaannn, sans déconner ! Pourtant quand je relis la news...
qui consiste à balancer une réponse méprisante à son petit camarade et à réfléchir après
Euh, c'étais pas du mépris, c'étais de l'énervement sur une news qui tente de proposer SQLite comme saint graal de la persistance de données.
Pour ton document, il ne m'apprend pas grand chose, je suis de toute façon d'accord sur le fond, et je sais ce qu'il en est des perfs XML vs Relationnel.
Mais franchement, dans une application local, parser et mapper un document XML faire tous les traitements sur les données sous forme d'objet, c'est souvent plus performant que de s'amuser à faire des requêtes dès qu'on veut toucher aux données... ou alors on utilise le même principe de mapping et on perd une bonne partie de l'intérêt... Et c'est pour celà que je trouve SQLite particulièrement inutile dans beaucoup de situation, il va sacrifier l'interopérabilité et parfois les performances pour celui qui s'amuse à faire des requêtes à tout va sans mapping (c'est à dire le même qui fait une petite application en local rapidos).
-->Nombre important de données à gérer, attaquable à distance par plusieurs utilisateur : un vrai SGBD
---> au milieu SQLite (solution avec un avantage de la solution précédente + les inconvénients de la solution en dessous, hem.)
-->Nombre plus restreind d'information, souvent en local, partageable mais pas en même temps : XML
[^] # Re: pfff
Posté par Fabimaru (site web personnel) . Évalué à 3.
[^] # Re: pfff
Posté par Christophe Renard . Évalué à 4.
A mes yeux le XML n'est pas plus souple à utiliser, ca ressemble bougrement à une base de donnée hyérachique(http://en.wikipedia.org/wiki/Hierarchical_database(...)) sur lesquelles les SGBDR ont été une innovation considérable. Croiser des infos en XML n'a rien de trivial.
Bref XML est bien sympa pour échanger des infos mais rarement pour les traiter.
"un SGBD peut être une bonne solution, mais c'est loin d'être pertinent dans toutes les applications. Voilà c'est mon avis sur cette publicité. " 100% d'accord !
Enfin n'oublions pas que SQLite ne s'inscrit pas en concurent de serveur de base de données, mais au contraire plutot comme une librairie à intégrer dans une application pour gérer ses données de façon rapide et flexible.
Le XML est par contre un excellent candidat aux fonctions d'import/export/sauvegarde/echanges reseaux ....
[^] # Re: pfff
Posté par Éric (site web personnel) . Évalué à 6.
- hyper verbeux (mauvais stockage, lecture de plein d'infos uniquement pour réperer un début de section)
- aucune structure fixe (on est obligé de tout interpréter pour comprendre, on ne peut pas sauter directement la balise quand on sait qu'elle ne sert pas)
- pas d'index (quand tu vas chercher une info en connaissant sa position exacte ça va, quand tu fais une recherche ça commence à dérraper coté perfs, surtout si c'est une recherche peu précise)
Le XML c'est pas vraiment fait pour les traitements internes tout de même. Ce n'est pas étudié pour ça (contrairement à un SGBD).
[^] # Re: pfff
Posté par Mouns (site web personnel) . Évalué à 1.
Oups, ca s'appelle une base XML ca :)
[^] # Re: pfff
Posté par Mouns (site web personnel) . É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.
# Undo/Redo
Posté par DiZ . Évalué à 5.
>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 ?
Il y a des frameworks/bibliothèques qui font ça :
Cocoa ou GNUstep par exemple :
http://developer.apple.com/documentation/Cocoa/Conceptual/UndoArchi(...)
http://developer.apple.com/documentation/Cocoa/Reference/Foundation(...)
A noter qu'il existe un adaptateur SQLite pour GNUstep database Library (GNUstep/Coaoa)
http://www.opengroupware.org/cvsweb/cvsweb.cgi/OpenGroupware.org/Da(...)
même si il est possible d'attaquer directement la base C...
[^] # Re: Undo/Redo
Posté par bobert . Évalué à 1.
You register an undo operation by specifying the object that is changing (or the owner of that object), along with a method to invoke to revert its state, and the arguments for that method.
Cette API ne fait donc que déplacer le problème : pour annuler le résultat d'une fonction f qui assure un certain traitement, il faut se cogner l'écriture de la fonction inverse f^{-1} et la passer à l'API...
Au contraire, en utilisant SQLite, l'annulation ne nécessite pas de coder de fonction inverse, elle se fait simplement en exploitant les propriétés du modèle relationnel.
[^] # Re: Undo/Redo
Posté par TImaniac (site web personnel) . Évalué à 2.
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...
Dans tous les cas faut fournir la fonction f^{-1} et là en l'occurence ce que propose l'auteur de cette news c'est de systématiquement faire des copies des tables, c'est le plus porc mais il est vrai le plus facile à faire (et parfois celà suffit largement), mais je ne vois vraiment pas en quoi celà est plus simple à mettre en oeuvre, faut se taper des triggers qui font office de fonction f^{-1} générique.
Il existe une méthode beaucoup plus répendu : le patron de conception Commande. Simple, efficace, et le Undo/Redo devient beaucoup plus simple à implémenter (on peut de la même manière faire une copie à la bourrine d'un objet, sans les contraintes de perf des accès SQL, ou bien faire encore plus propre et fournir la fonction f^{-1} spécifique) avec toutes les possiblités du langage de son choix sans être limité par le les triggers.
Bref, SQLite n'a rien d'innovant pour résoudre ce problème.
# Fiabilité !
Posté par j . Évalué à 4.
J'avoue que SQLite est très bon. La couche SQL permet de moins se prendre la tête par rapport à BerkeleyDB ou QDBM.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Fiabilité !
Posté par zorel . Évalué à 5.
[^] # Re: Fiabilité !
Posté par 007 . Évalué à 3.
Mieux vaux lire ça qu'être aveugle.
Aucun programme ne peut avoir la prétention de ne _jamais_ planter.
Et le "vu qu'il n'y a pas de serveur" je ne vois pas que qu'il fait ici.
[^] # Re: Fiabilité !
Posté par thaodalf . Évalué à 0.
donc au final on a gagner un peu plus de fiabilité.
[^] # Re: Fiabilité !
Posté par TImaniac (site web personnel) . Évalué à 3.
# Un fichier
Posté par 007 . Évalué à -4.
Un peu plus de "modération" ne peut pas faire de mal...
> en n'utilisant qu'un unique fichier de stockage !
C'est fantastique comme je m'en fous complêtement. Un fichier ou plusieurs fichiers dans un répertoire c'est du pareil au même.
À moins qu'il soit possible de stocker directement sur un périphérique de stockage sans FS.
[^] # Re: Un fichier
Posté par lezardbreton . Évalué à 7.
Je relativise quand même : SQLite n'est à priori pas fait pour être comparé à Terradata.
PS: Je peux me tromper. les serveurs mails sous Windows, j'y toucherais jamais.
# J'ai un peu utilisé SQLite...
Posté par Balise . Évalué à 10.
Par exemple, j'ai un vieux projet dans un coin de tiroir pour un soft de gestion de recettes de cuisine (l'existant me convient pas vraiment) avec comme fonctionnalité (inspirée largement des idées de ma cop' Céline) le fait de pouvoir graver un CD histoire de par exemple le trimballer chez mes parents et avoir ma base avec moi sans ennui.
Bon je sais bien qu'il y a tout un tas de trucs discutables, comme le fait ci-dessus qu'une solution à base de XML serait ptêt pas plus stupide pour des recettes (mais j'ai dans l'idée qu'une base relationnelle me permet bien plus de souplesse niveau requêtes/recherche), ou le fait que c'est peut-être possible avec d'autres SGBD et que je n'ai pas assez creusé le sujet.
Ceci dit peut-être cela peut-il donner des idées ;-)
# SQLite ca accèlère l'Internet ?
Posté par Guillaume Knispel . Évalué à 2.
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, [blablabla] ...
Bon j'ai capté le vrai sens de struc, mais si je le lis texto ca veut à peu près dire que SQLite ca enlarge your p3n1s et ca accélère l'Internet. Dès fois faut un peu penser aux types d'applications qu'on a pas l'habitude de coder avant d'écrire des choses pareils.
[^] # Re: SQLite ca accèlère l'Internet ?
Posté par bobert . Évalué à 2.
Prenons un projet libre lambda. Le développeur de lambda a choisi comme format de stockage
- le XML, parce que ça fait hype et qu'il y a des tas d'API pour grignoter du XML, alors pourquoi s'emmerder, hein ?
- tout ça compressé via gzip
Bon, et mettons qu'un utilisateur de lambda arrive à 1000 enregistrements, ou unités d'informations pour le logiciel lambda. Ça, c'est du quotidien, c'est le cas par exemple de mes bookmarks sous Konqueror, j'en ai plus d'un millier, stockés bien évidemment comme il se doit dans un bon gros fichier xml.
Or ce que je prétends quand j'écris "Sans rien faire, il y a des chances que SQLite soit plus rapide que vous pour [...]", c'est tout bêtement que ces mêmes données stockées sous forme relationnelle dans un fichier de données SQLite, seront accédées beaucoup plus rapidement, à la louche je dirais de 100 à 1000 fois plus vite.
Avant d'y aller de ton petit commentaire méprisant, réfléchis-y juste 5 minutes ; relis l'article de Spolsky sur le B-A-BA du traitement de données XML / relationnel, que j'ai cité plus haut.
Moi j'y pense à chaque fois que konqueror mouline pour ajouter un bookmark, tout ça parce que le format choisi (XBEL) est un format d'échange et pas de stockage
[^] # Re: SQLite ca accèlère l'Internet ?
Posté par 007 . Évalué à 1.
Ça dépend. Pour une recherche ET si tu as le bon index alors peut-être (il faut beaucoup de données). Pour récupérer toute la liste, c'est beaucoup moins sûr.
Je dis ça de façon général et pas par rapport à XML.
J'ai déjà constaté que pour des petites tables un index n'apporte rien en recherche et est pénalisant lors des mises à jour/ajout/suppression.
La "forme relationnelle" a un sens avec plus d'une table :-)
[^] # Re: SQLite ca accèlère l'Internet ?
Posté par Cali_Mero . Évalué à 3.
Les SGBD, c'est bien seulement quand on sait s'en servir.
[^] # Re: SQLite ca accèlère l'Internet ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 8.
Dans le cas des bookmarks de konq, je présume qu'ils passent par DOM plutôt que SAX pour les lire (ça serait logique vu qu'ils sont présentés comme un arbre), donc il est évident que tu vas manger un peu coté perfs. Ceci dit, pour seulement 1000 enregistrements, je ne crois pas que cela soit très sensible, le ralentissement viens plutôt de l'infrastructure de KDE qui maintient les bookmarks de manière centralisée.
Ce que tu ne veux pas comprendre c'est que le gain de vitesse dont tu parles, dans 99% des cas d'applis end-user, on s'en fout complètement, ça fait une différence négligeable. Par contre, avoir un format de fichier robuste et qui se lit facilement, ÇA ça fait une énorme différence pour le développeur, et pour l'utilisateur au final parce qu'il perdra moins souvent ses data.
Je viens de faire un test tout con : grep sur un fichier de 600 000 lignes (six cent mille, plus d'un demi-million). Le fichier fait 33Mb au total. grep bouffe ça en 0.04 secondes, sur mon P4 2.4GHz, une machine vieille de 2 ans. 4 centièmes de secondes pour scanner une regexp sur 33Mb. Tu es sur d'avoir si souvent besoin d'une DB ?
Donc pour ce qui est d'aller reflechir et des commentaires méprisants, pour l'instant c'est plutôt toi qui croit avoir compris un truc ("SQLLite c'est bon, mangez-en") et qui pense que les autres sont des truffes de ne pas l'avoir compris, alors que dès que tu as 2 sous d'expérience, le truc que tu apprends (souvent douloureusement), c'est "les DBs c'est sympa mais faut pas en abuser".
[^] # Re: SQLite ca accèlère l'Internet ?
Posté par Guillaume Knispel . Évalué à 6.
Apparement il s'agit plus d'un malentendu qu'autre chose, mais pour éviter d'avoir le même problème j'éviterais de faire du xième degré au goût douteux à l'avenir.
Ce que je voulais dire, c'est qu'effectivement il peut être interressant d'utiliser SQLite pour accelerer certains types d'opérations d'accès aux données. Mais il existe des cas qui sortent très largement du cadre d'opération de SQLite, et ta réponse ci-dessus montre que ce fait n'a toujours pas éfleré ton esprit... Je maintient donc l'idée sous jacente de mon commentaire précédent, en vous priant à tous d'en oublier le ton et le mode d'écriture inadapté.
Si j'ai formulé ça aussi débilement, c'est en réaction un peu disproportionné au ton général de l'article, qui dit en substance : mettez du SQLite partout car c'est un logiciel parfait qui accèlère n'importe quel prog en 15 lignes de code. (note : la phrase précédente est une exagération à 1000% ne représentant qu'une caricature extrème et inutile des idées de l'article, bref du xième degré mais pas de goût douteux, donc je me laisse le droit de l'utiliser :)
Or quand on me dit ça, ou quand la formulation des phrases laisse place à une ambiguïté même minime pouvant déboucher en utilisant des hypothèses de compréhensions un peu tordues j'en conviens, j'ai du mal à le croire, mais crois bien que la prochaine fois que j'écrirais un prog ayant besoin d'effectuer des accès à des données de manière rentrant dans le cadre d'opération de SQLite, j'envisagerais sérieusement la possibilité de l'utiliser.
[^] # Re: SQLite ca accèlère l'Internet ?
Posté par TImaniac (site web personnel) . Évalué à 2.
# Oui... pour les toutes petites bases !!
Posté par AP . Évalué à 6.
Cela-dit, avec la couche d'abstraction ad-hoc, on peut commencer pas faire des tests en SQLite puis migrer de façon transparente vers une autre solution de gestion de bases de données une fois en production ou dès que l'application atteindra un certain volume de données stockées...
[^] # Re: Oui... pour les toutes petites bases !!
Posté par bobert . Évalué à 1.
Ah bon ? Qu'est-ce que tu en sais, personnellement ? Tu as des tests à l'appui ?
Au hasard, extrait de la mailing-list SQLite du 25 Janvier 2003:
> A 32-bit primary key limits the number of entries in a single table
> to 2^32. But each such entry must be at least 24 bytes in size so
> we are already dealing with a 100GB database. And you can have
> multiple tables. So I don't think this is really a problem.
Ça laisse tout de même de quoi voir venir, hmm ?
De toute façon mon propos n'était pas de jouer les vendeurs de benchmarks de SGBD, on sait tous que ça ne rime à rien.
Il s'agit simplement de proposer à un développeur de logiciel libre (pas à une compagnie d'assurance hein, un gars qui code un client de courrier, un lecteur de news, un outil de dessin, que sais-je, la plupart des applications qu'on peut trouver sur un poste de bureau sous Linux), que ça peut être très judicieux d'utiliser SQLite pour assurer la persistance de ses données, point barre.
Et dans ce contexte, ça n'a aucun intérêt de faire la course aux gigaoctets ou aux millions de transactions par seconde, c'est pas le débat. Mais par contre, SQLite gère très bien une volumétrie beaucoup plus importante que ce que tu imagines.
[^] # Re: Oui... pour les toutes petites bases !!
Posté par 007 . Évalué à 1.
Ça c'est sans le moindre intérêt. Ça montre seulement que lors du développement ils ont fait attention. Berkeley DB en fait autant.
> De toute façon mon propos n'était pas de jouer les vendeurs de benchmarks de SGBD
Faut pas laisser croire que SQLite est dans la cour des "grands" avec ou sans benchmarks.
- Implémente la plus grande partie de la norme SQL92, dont les triggers et les transactions
Sur plusieurs tables à la fois les transactions ?
Peut-on ouvrir plusieurs transactions en écriture à la fois sur la même table (genre réservation de billets d'avion par plusieurs personnes à la fois)?
Dans la norme SQL92 supporte-il la majorité des types ou qu'un ensemble très limité comme "INTEGER, REAL, TEXT et BLOB" ? Il y a les types decimal ou numeric à précision arbitraire ?
Il y a les sous-requêtes ? Il y a la clause "HAVING" ?
- Offre des performances supérieures à PostgreSQL et même MySQL pour beaucoup de types de requêtes communes
C'est suffisament vague pour que tu ne le prouves pas...
2. Offrir à l'utilisateur un niveau illimité d'annuler/refaire
Berkeley DB qui supporte aussi les transactions fait ça sans "artifice". Parce que avec les triggers n'importe quel gestionnaire peut faire ça.
btw, Berkeley DB supporte aussi les backups à chaud avec une simplicité désarmente. Il suffit de copier les fichiers. C'est tout.
J'ai rien contre SQLite. Mais la pub avec des arguments "tendancieux" sur dlfp m'énerve beaucoup. J'ai l'impression de les publicitaires MS n'aurait pas fait mieux que toi.
[^] # Re: Oui... pour les toutes petites bases !!
Posté par Christophe Renard . Évalué à 2.
# lire attentivement
Posté par - - . Évalué à 10.
je lis des avis de gens TRES compétents, mais TRES distrait
l'auteur de l'article dit EXPLICITEMENT d'utiliser SQLite dans le cadre d'applications de BUREAU, exemple farfelu qui me passe par la tête : rhythmbox, la base des albums de GThumb, etc etc
mais vous foncez tout de suite critiquer sqlite (à croire que cela vous dérange que quelqu'un en pense du bien) en cherchant les cas les plus ardus, les cas très demandeur qui ont besoin d'une architecture client-serveur . Mais l'auteur de l'article lui ne parle que des besoins de stockage SIMPLE mais régulièrement manipulé par des applications BUREAUTIQUES libres.
PAS plus
et pour le reste, mais évidemment que mysql ou oracle ou autre c'est plus puissant et mieux conçus etc personne ne dit le contraire
il dit juste : pour les applications bureautiques qui stockent des données, plutôt que de réinventer la roue (et peu semblent utiliser berkeley DB) il serait bien intéressant de considérer ces moteurs embarqués de stockage.
ni plus ni moins, inutile de venir casser sqlite ou de défendre oracle, il est évident que vous ne parlez pas des même soucis et problèmes.
[^] # Re: lire attentivement
Posté par 007 . Évalué à 8.
Personne ne dit que SQLite est nul. Le problème est de comparer SQLite avec MySQL ou PostgreSQL. SQLite n'a rien à voir avec MySQL et encore moins avec PostgreSQL.
Ce qui est critiqué c'est le FUD de la news.
Exemple :
Disons en deux mots qu'il a tout d'un grand
C'est du foutage de gueule.
Implémente la plus grande partie de la norme SQL92, dont les triggers et les transactions
Et pas de language embarqué...
Voir :
http://www.sqlite.org/omitted.html(...)
Et aussi :
http://www.sqlite.org/cvstrac/wiki?p=UnsupportedSql(...)
Et j'ai bien l'impression que c'est pas complet.
Implémenter une caractéristique de SQL92 peut-être extrêment dure (par exemple les sous-requêtes et de façon complète). Pour affirmer que la plus grande partie de la norme SQL92 est implémentée il ne suffit pas d'avoir SELECT, INSERT, DELETE et UPDATE ou d'avoir plus de 50 % des mots clés de supportés.
- Supporte les transactions avec toutes les propriétés d'atomicité, de consistence, d'isolation et de durabilité (ACID)
Pour une table ! Le contexte de transaction peut-être très complexe. Juste pour exemple, je te conseil de lire (ce n'est pas long) :
http://www.postgresql.org/docs/7.4/static/mvcc.html(...)
Offre des performances supérieures à PostgreSQL et même MySQL pour beaucoup de types de requêtes communes
Mais quelle surprise ! Cette comparaison est stupide. Tout est réalisé sur une seul table et jamais avec plusieurs client à la foi. Comment ça ce comporte sur une machine smp ? Mistère...
Si j'étais aussi "bête" je ferait bien un comparatif/bench entre PostgreSQL et SQLite. Il y aurait plein de "failed" pour SQLite et dans quelque cas SQLite serait plus rapide. Mais ce serait stupide.
Bref, j'ai pas envis d'en discuter longtemps. SQLite n'a presque rien d'un grand. C'est un petit et il le fait très bien. Il n'est pas conçu pour être un grand.
Il faut le comparer à Berkeley DB (qui a les transactions sur une table (ACID) prend peu de place mémoire et est aussi extrèment rapide). btw Berkeley DB a aussi un mode serveur.
On compare un ananas avec une patate seulement parce que ça se mange. Ça me gonffle. L'ananas ce n'est pas terrible avec une côte de boeuf grillé et la tarte aux patates j'aime pas ça. NB: Je bouffe des ananas et des patates.
Pour finir positivement, SQLite me plait beaucoup et nul doute que j'y penserais si je travail sur un projet qui "cadre" avec ce pour quoi il a été fait.
[^] # Re: lire attentivement
Posté par 007 . Évalué à -2.
Beaucoup de choses marquées spécifiques à Oracle existent dans PostgreSQL.
[^] # Re: lire attentivement
Posté par bobert . Évalué à 1.
Ce qui est critiqué c'est le FUD de la news.
Exemple :
Disons en deux mots qu'il a tout d'un grand
Oh la la... alors quand tu entends dire d'une petite bagnole qu'elle a tout d'une grande, tu vas crier au FUD parce qu'on a osé fairela comparaison avec ta grosse caisse avec ses 6 cylindres en Vrac ??
> Offre des performances supérieures à PostgreSQL et même MySQL pour beaucoup de types de requêtes communes
Mais quelle surprise ! Cette comparaison est stupide. [...]
Merci pour l'adverbe, tout cela est très constructif.
Comme déjà dit, je ne me situais pas dans le contexte des applications client-serveur (encore que je serais ravi d'avoir une petite causerie là-dessus)
Il s'agissais simplement de considérer des applications indépendante sur un poste linux, par exemple de bureautique ; dans ce contexte, il y a des logiciels qui utilisent déjà des SGBD en mode client-serveur comme Postgres et MySQL, pour gérer leurs données ; je parle des tonnes d'outils de gestion de collection de mp3, de gestionnaires / créateurs d'albums photo (e.g. Zoph, Atomic Photo Album), de bookmarks, de notes, etc.
Pour toutes ces applications, ça a bien un sens de se demander, "tiens, et si au lieu de mettre en branle postgresql pour gérer mes 2 Mo de données, j'utilisais tout connement SQLite ?"
Et avant de chipoter sur ce que propose / ne propose pas SQLite, fais simplement la part des besoins des applications sus-citées. Ont-elles besoin d'un PL/SQL de la mort ? Ont-elles besoin d'un SGBD qui tourne en mode serveur, dont la mise en place échoit à l'utilisateur final ?
Si j'étais aussi "bête"
Mais non, tu as raison, c'est bien toi le plus intelligent. C'est un plaisir que de mener une conversation avec un être suprême comme toi.
[^] # Re: lire attentivement
Posté par Éric (site web personnel) . Évalué à 5.
Tu remarqueras que ni le message auquel tu répond ni la news ne comparent avec MySQL et pgSQL. Et dans les commentaires les comparaisons des "pro-sqlite" se contentent de parler des perfs dans une utilisation simple et courante (donc là où sqlite est pertinent)
> Et pas de language embarqué...
MySQL non plus. Et pour la suite c'est pareil, Le jeu de fonctionnalité est presque plus petit sur MySQL 3.23 que sur SQLite.
Tu compares avec MysqL mais jusqu'à encore récement MysQL n'avait pas de transaction (pas de faibles comme SQLite, pas du tout), pas de requêtes imbriquées (pas même des limitées type sqlite), manque de beaucoup de mots clés aussi, .... ça n'a pas empêché *énormément* de monde d'utiliser mysql 3.23 (et de l'utiliser toujours).
Alors déjà à la base pour moi ça veut dire qu'une comparaison avec le gros MySQL n'est pas si idiote que tu le laisses sous entendre.
Oui ça ne supporte pas forcément tout (pas plus que les autres d'ailleurs), oui le modèle transactionnel n'est probablement pas fait pour avoir une super grosse concurrence, maintenant est-ce grave ?
Pour la plupart des application bureau il n'y a pas besoin de tout ça, et pour pas mal de petites appli client-serveur ça suffit largement aussi. Et quand ça suffit on gagne justement beaucoup par rapport à mysql ou pgsql sur le fait de ne pas avoir besoin d'installer/configurer un gros serveur (par exemple).
Je me vois mal demander l'installation de MySQL pour mon aggregateur RSS.
[^] # Re: lire attentivement
Posté par 007 . Évalué à 0.
De la news :
Offre des performances supérieures à PostgreSQL et même MySQL pour beaucoup de types de requêtes communes
> n'est probablement pas fait pour avoir une super grosse concurrence, maintenant est-ce grave ?
Non.
[^] # Re: lire attentivement
Posté par thaodalf . Évalué à 1.
a chaque fois tu nous cette phrase qui parle de mysql et postgresql mais t'oublie tous le contexte de la niouze, tu serais pas un utilisateur tenace des ces sgbd ? un peu fanatique aussi ?
[^] # Re: lire attentivement
Posté par 007 . Évalué à 1.
http://www.sqlite.org/faq.html#q2(...)
What datatypes does SQLite support?
SQLite is typeless. All data is stored as null-terminated strings.
Comme faire des comparaisons de date ou des calculs sur des dates ?
Comment est supporté les locales pour les dates (heure été/hiver :p) ou les chiffres ?
Ce n'est pas une critique de SQLite. Ça montre que SQLite n'est pas un équivalent d'un "vrai" SGBD.
[^] # Re: lire attentivement
Posté par Cali_Mero . Évalué à 4.
[^] # Re: lire attentivement
Posté par Éric (site web personnel) . Évalué à 5.
Si tes dates sont stockées sous forme classique (2004-06-31 19:53:21) la comparaison se fait toute seule. Pour les calculs SQLite sait utiliser des fonctions qu'on lui exporte. Rien ne t'empêche de lui exporter un date_sub() ou date_add().
> Comment est supporté les locales pour les dates
Je ne sais pas toi, mais moi ce que je stockes je le normalise avant. En gros tout ce qui est stocké a la même forme et le même fuseau horaire. Note que c'est aussi ce que fait ce que tu appelles un "vrai" SGBD.
> ou les chiffres ?
Si tu lis la news et les liens tu verras que justement depuis cette version il y a un typage simple mis en oeuvre pour distinguer int/float/text/blob
Avant ça utilisait le type de la colonne (on en déclarait bien un, même s'il ne forcait rien au niveau stockage des données) pour savoir comment trier les données par défaut (comme des chiffres ou comme des textes).
> Ça montre que SQLite n'est pas un équivalent d'un "vrai" SGBD.
Je comprend mal la relation entre le corps du message et la conclusion. Quelqu'un peut me rappeler en quoi un SGBD doit fournir des fonctions de traitement de date pour avoir le droit d'être un "système de gestion de base de données" ?
[^] # Re: lire attentivement
Posté par 007 . Évalué à 0.
Marche pas avec le passage heure d'été/hiver. Il faut un "truc" supplémentaire. Par exemple stocker les heures en GMT. Puis c'est a toi de prendre en compte les locales. C'est lourd. PostgreSQL fait ça tout seul. De plus tu ne peux pas faire de différence de date avec SQLite (par exemple).
> Si tu lis la news et les liens tu verras que justement depuis cette version il y a un typage simple mis en oeuvre pour distinguer int/float/text/blob
Faut aller lire le site. Il n'y a pas de vrai typage. Les données restent stockées en string.
Vas lire le site attentivement.
> Quelqu'un peut me rappeler en quoi un SGBD doit fournir des fonctions de traitement de date pour avoir le droit d'être un "système de gestion de base de données" ?
Stocker des données et ne pas pouvoir faire de traitement (par exemple soustraction) n'est "pas top".
[^] # Re: lire attentivement
Posté par Éric (site web personnel) . Évalué à 2.
> stockées en string.
> Vas lire le site attentivement.
Je cite http://www.sqlite.org/datatype3.html(...)
"Version 2 of SQLite stores all column values as ASCII text. Version 3 enhances this by providing the ability to store integer and real numbers in a more compact format"
Maintenant ce qui m'intéresse ce n'est pas comment c'est stocké (ça c'est sa sauce interne) mais comment c'est traité. Si moi j'envoie des nombres, je recois des nombres, je trie des nombre, je soustrais ou additionne des nombres ... Je me fiche de savoir si c'est stocké en interne en ascii, en binaire ou avec une méthode alamabiquée. C'est bien un des intérêts de l'abstraction faite avec les DB : ne pas gérer le stockage.
> Stocker des données et ne pas pouvoir faire de traitement (par exemple soustraction) n'est "pas top".
Je suppose que ton langage de prog a des fonctions de traitement de date, il suffit de les exporter.
[^] # Re: lire attentivement
Posté par Cali_Mero . Évalué à 2.
Je ne parlerai pas des différences tellement flagrantes entre les deux SGBD que tout le monde ici doit connaître (PostgreSQL est un serveur tandis que SQLite est une bibliothèque, etc...).
Si tu prends en compte cette différence d'objectif (qui indique clairement que les deux projets partent dans des directions opposées dépouillement<>richesse), ca veut tout simplement dire que le choix entre l'un est l'autre t'es permis, suivant tes besoins et l'application sur laquelle tu veux greffer un SGBD. Mais déclarer unilatéralement que l'un n'est pas un "vrai" parcequ'il n'offre pas toutes les caractéristiques de l'autre, c'est une critique totalement aveugle et partisane (autant que le ton général de la news tu me diras...).
Autant soutenir que la smart n'est pas une voiture car elle n'offre que 2 places et un tout petit coffre, une voiture étant à la base faite pour le transport de passagers et/ou d'objets, c'est aussi stérile que ta remarque.
[^] # Re: lire attentivement
Posté par 007 . Évalué à 0.
[^] # Re: lire attentivement
Posté par Mildred (site web personnel) . Évalué à 1.
Ca semble marcher correctement dans le petit wiki que j'ai fait avec SQLite
[^] # Re: lire attentivement
Posté par TImaniac (site web personnel) . Évalué à 2.
Et là il faut tout de suite s'imaginer qu'on va avoir affaire avec des accès concurrents, plusieurs applis qui exploitent les même informations, et si la moindre appli peut vérouiller la base et bloquer toutes les autres ca va rigoler sec. Comme quoi même en bureautique SQLite peut être un mauvais choix.
[^] # Re: lire attentivement
Posté par Éric (site web personnel) . Évalué à 3.
Pour rappel, quel que soit le système, soit tu autorises un lock et dans ce cas là quand un process lock ça bloque tous les autres en écriture, soit tu ne fais pas de lock et là bonne chance à tes données lors des accès concurrents. Et ça c'est strictement le même problème avec tes trois carnets d'adresse en XML.
Tu as une autre solution ? à part installer un gros SGBD pour les applications bureautiques ?
[^] # Re: lire attentivement
Posté par TImaniac (site web personnel) . Évalué à 2.
Mais ce n'est pas pour celà que je préconise toujours le XML, et là en l'occurence ce n'est pas le cas. Effectivement installer un "GROS" SGBD pour les applications bureautique n'est peut être pas LA meilleur solution (lourdeur, inadapté), peut être un système plus léger, issu d'un MySQL par exemple, qui serait plus adapté à l'environnement bureautique et qui serait intégré à l'environnement, un peu comme le WinFS que je mentionnais chez nos amis de Redmond. Dans l'environnement Gnome il y a déjà ce genre d'idée de partage du carnet d'adresse par exemple, et je trouve l'idée très intéressante de présenter les données de l'utilisateur à un niveau plus élevé que l'arbre du système de fichier.
# Mckoi
Posté par Frédéric Desmoulins (site web personnel) . Évalué à 2.
Mckoi: http://mckoi.com/database/(...)
[^] # Re: Mckoi
Posté par B r u n o (site web personnel) . Évalué à 6.
Il y a aussi Axion dans la catégorie ( http://axion.tigris.org(...) ). Il y avait InstantDB à une époque, mais je n'arrive plus à mettre la main dessus, c'était fait par Lutris je crois - ceux qui sont à l'origine de Enhydra - et je ne retrouve plus de trace sur ObjectWeb qui héberge maintenant le projet.
# SQLite c'est super mais...
Posté par Alexandre Dulaunoy (site web personnel) . Évalué à 6.
Mais lorsque l'interface SQL est de trop (cela peut arriver), alors on se tourne souvent vers les dbs "flat-files". Comme SDBM, GDBM et même CDB (hé oui, on ne peut pas toujours choisir l'auteur)... Mais dans cette série, il ne faut pas oublier QDBM (http://qdbm.sf.net/(...)). Très rapide, flexible (stockage variable, des outils externes pour gérer les fichiers) et le projet évolue bien...
Less is sometimes better...
# Aussi pour de petits sites
Posté par Robert VISEUR (site web personnel) . Évalué à 4.
Sur Online par exemple, la serveur MySQL est très lent (je suppose que les temps de connexion au SGBD y sont aussi pour quelque chose). En plus, je n'ai pas accès aux tables de la base de données MySQL. Mes forums génèrent un trafic plutôt faible, surtout en écriture.
Dès lors, pour ce genre d'applications, je serais très intéressé par utiliser une base de données fichier du type SQL Lite (que je pourrais en plus modifier en local chez mois puis remettre en ligne). Malheureusement, Online ne semble pas supporter cette base de données (si qqn a plus d'infos à ce propos, je suis preneur).
Pour la bureautique, il manquait clairement un Access-like dans les suites du type Open Office (depuis six mois, j'avoue ne plus trop avoir suivi mais ça revenait souvent). Je pense que le jour où Open Office sera intégré avec un SQL Lite (ou assimilé) de manière pleinement fonctionnelle (i.e. avec un envirronnement de développement graphique de type Access), un argument pour rester sous MS Office aura tombé (deux problèmes reviennent souvent dans les échecs de migration vers OOo : pas d'Access-like valable et problème de calendrier Outlook).
[^] # Re: Aussi pour de petits sites
Posté par Cali_Mero . Évalué à 7.
- Il est facile de foutre un serveur mysql par terre avec une requete bien lourde qui ramène 3 millions d'enregistrements avec des jointures débiles, et là tous les hébergés souffrent du serveur qui tombe, pas seulement le crétin qui l'a fait tomber.
- La charge des serveurs mysql chez les gros hébergeurs mutualisés est souvent énorme et là aussi, tous les clients en souffrent (c'est encore plus vrai chez les hébergeurs gratuits, je pense notamment à free...). Les webmasters installent des scripts genre phpnuke sans se poser trop de questions et s'étonnent après que le serveur ralentisse jour après jour...
SQLite devrait contribuer à régler ces problèmes : on ne pourra plus crasher le serveur de bases de données commun, on pourra seulement crasher son propre process sans impacter les autres clients. De plus, cette individualisation de la charge rendra plus facile sà débusquer les clients qui abusent, par ignorance ou par bêtise, des (précieuses) ressources du serveur mutualisé.
Enfin, toujours dans le contexte spécifique du web, SQLite s'installe très facilement puisqu'il s'agit d'une simple extension php : on devrait donc la trouver absolument partout, alors que tous les hébergements web GNU/Linux
-apache-php actuels ne proposent pas systématiquement de base mysql associée (très souvent, mais pas toujours, notamment pour les moins chers et les gratuits, en partie à cause des raisons que j'ai évoquées plus haut).
[^] # Re: Aussi pour de petits sites
Posté par Éric (site web personnel) . Évalué à 4.
On permet aussi des sauvegardes simplifiées ou la possibilité de dire au client pas cher "démerdes toi, il n'y a rien de réservé à l'administrateur"
> Il est facile de foutre un serveur mysql par terre
ça ne changera rien pour les mutualisés, on foutra le process Apache par terre (vu que c'est lui qui fera le boulot). Je ne sais pas si c'est mieux.
> De plus, cette individualisation de la charge rendra plus facile sà débusquer les clients
Ça c'est plutot le contraire, vu que tu ne pourras pas savoir qui provoque la charge (avec un serveur central tu peux compter les connexion ou regarder à un instant T qui est connecté).
SQlite ne génère qu'une requête d'ouverture de fichier en lecture/écriture, sauf à patcher les librairies systèmes je vois mal comment tu peux savoir qui charge ton serveur.
> puisqu'il s'agit d'une simple extension php
C'est même mieux : c'est une extension PHP fournie/compilée par défaut.
[^] # Re: Aussi pour de petits sites
Posté par Cali_Mero . Évalué à 2.
Tout à fait, et tu as bien raison de le préciser : il y a là une considération importante à prendre en compte, à savoir que la sécurité d'une base SQLite comparée à son équivalent MySQL est nulle par défaut... C'est un simple fichier qui peut se retrouver accessible et téléchargeable par http si on n'y fait pas gaffe. La sécurité des données se trouve du coup à la charge du développeur, à grands coups de .htaccess.
ça ne changera rien pour les mutualisés, on foutra le process Apache par terre (vu que c'est lui qui fera le boulot). Je ne sais pas si c'est mieux.
J'avoue que je n'ai pas essayé. Ceci dit, je n'ai encore jamais crashé un apache bien configuré... Tu as testé ? Si oui, raconte nous ton expérience stp, ca m'intéresse beaucoup.
Ça c'est plutot le contraire, vu que tu ne pourras pas savoir qui provoque la charge (avec un serveur central tu peux compter les connexion ou regarder à un instant T qui est connecté).
SQlite ne génère qu'une requête d'ouverture de fichier en lecture/écriture, sauf à patcher les librairies systèmes je vois mal comment tu peux savoir qui charge ton serveur.
Patcher les librairies, quand tu prends en charge un tel hébergement, c'est pas un gros boulot et ca devrait être dans les cordes de tout admin qui se respecte. Je pense même que la plupart des serveurs mutualisés sont patchés à un moment ou à un autre de leur existence... Mais il y a bien d'autres façons d'y arriver.
Et dans le pire des cas, si, comme tu le décris plus haut, SQLite arrive à faire crasher le process apache (ce que je ne pense pas), Trouver le responsable et envoyer un mail automatique à l'admin n'est pas bien difficile à faire... Pas plus que de redémarrer apache immédiatement d'ailleurs, de sorte que la coupure soit la plus courte possible.
[^] # Re: Aussi pour de petits sites
Posté par Antoine . Évalué à 2.
Il y a quelqu'un qui a réussi ici :
http://www.neokraft.net/blog/2004/06/17/515-comparaison-spip-spip-a(...)
[^] # Re: Aussi pour de petits sites
Posté par Éric (site web personnel) . Évalué à 3.
> nulle par défaut...
C'est tout de même considérer que la sécurité des droits d'accès de ton système est nulle par défaut, ce qui me parait un peut exagérer.
Pour info Mysql aussi stockes sur des fichiers, et la protection des fichiers de Mysql est dépendante des droits d'accès de ces fichiers.
Si tu considère que ces droits d'accès n'offrent aucune protection alors permet moi de te dire que ni mysql ni postgresql n'offrent de protection.
Les serveurs de SGBD n'offrent pas plus de protection, ils offrent une gestion plus fine des droits d'accès (au niveau des partages et des utilisateurs multiples). À la limite si tu as un FS avec des ACL la sécurité sera strictement identique.
> C'est un simple fichier qui peut se retrouver accessible et téléchargeable par http
Si tu en es là il me semble que tu peux arrêter de disserter sur la gestion de la sécu. Le minimum c'est de mettre ta db en dehors de l'arbre exporté par le serveur Web. Les autres SGBD le font bien non ? :)
Ça c'est vraiment des mauvas arguments que tu nous sors
> Ceci dit, je n'ai encore jamais crashé un apache bien configuré...
Faire dérapper un Apache parce que des scripts PHP moulinent dedans n'importe comment ça m'arrive régulièrement sur la plate-forme de dev (et chez moi et au boulot).
> Patcher les librairies, quand tu prends en charge un tel
> hébergement, c'est pas un gros boulot et ca devrait être dans les
> cordes de tout admin qui se respecte.
Ça me parait une superbe ouverture pour rajouter des bugs ou pb de sécurité, enfin bon. Par contre tu parlais d'une surveillance plus simple, je suis interloqué que tu trouves que patcher les libs système soit plus simple que les outils de surveillances que doit t'offrir par défaut un SGBD classique.
> Trouver le responsable et envoyer un mail automatique à l'admin
> n'est pas bien difficile à faire... Pas plus que de redémarrer
> apache immédiatement d'ailleurs, de sorte que la coupure soit la
> plus courte possible.
Parce que ce n'est pas vrai pour le SGBD qui tombe dont tu parlais plus haut ?
[^] # Re: Aussi pour de petits sites
Posté par Cali_Mero . Évalué à 1.
Ça c'est vraiment des mauvas arguments que tu nous sors
Ben moi je pense que tu ne vois pas de quoi je parle. Je parle à ceux qui nous lisent et qui n'ont pas tous essayé SQLite, en particulier sur un hébergement web mutualisé (sujet que je connais particulièrement bien). Si tu vas chez l'hébergeur du coin les bases MySQL sont stockées dans un répertoire inaccessible depuis le web, cela va de soi, c'est l'administrateur du serveur qui a fait les choses dans ce sens (un type sensé avoir les compétences en sécurité pour faire les choses qui vont bien). Je te rejoins quand tu dis que les fichiers ne sont pas plus sécurisés sur un SGBD que sur l'autre, mais la différence est que dans le cas de MySQL, l'admin a fait tout le boulot pour sécuriser les fichiers : dans le cas de SQLite, tout est à la charge de l'utilisateur. C'est lui l'administrateur qui gère la sécurité de sa base, sachant que le fichier concerné doit bien sûr avoir des permissions suffisantes pour faire des choses dessus avec le serveur web... Je ne pense pas qu'il soit inutile de le dire ici, sans doute tu as suffisament joué avec la chose pour considérer cela comme acquis, mais ce n'est certainement pas le cas de tout un chacun.
Je ne cherche pas tant à argumenter avec toi qu'à apporter de l'information utile à ceux qui ne se sont pas encore fait leur idée sur SQLite et sur des cas pratiques. Regarde en bas de cette page, il y en a... (Y'en a même qui vont acheter des bouquins sur le sujet, tu imagines ?)
> Ceci dit, je n'ai encore jamais crashé un apache bien configuré...
J'ai pas du etre assez clair en parlant de "bien configuré" : mon apache 1.3.27 d'easyphp sur ma machine de dev du boulot (sous windows, désolé, pas le choix), je le crashe au moins une fois par mois... ne serait-ce qu'avec la GD. Idem chez moi.
Mais un apache 2, sous GNU/linux, configuré et compilé convenablement, c'est autrement plus résistant, je maintiens.
Ça me parait une superbe ouverture pour rajouter des bugs ou pb de sécurité, enfin bon.
Tout dépend des patchs. Dois-je réellement t'expliquer à quel point ca peut rendre service de pouvoir modifier les sources et recompiler à volonté les programmes qu'on utilise tous les jours ?
Parce que ce n'est pas vrai pour le SGBD qui tombe dont tu parlais plus haut ?
également, ceci dit, un site dynamique sans sa base de données a peu d'intêret, tout comme un SGBD sans site pour l'attaquer. Je pense qu'il est plus aisé de gérer la sécurité et la fiabilité d'un seul démon plutot que de deux (qui de surcroit n'ont pas grand chose à voir l'un avec l'autre).
[^] # Re: Aussi pour de petits sites
Posté par Antoine . Évalué à 2.
De mon expérience, le problème de performances avec PHP/MySQL se situe du côté de PHP, pas de MySQL. Bien sûr, cela dépend probablement des programmes.
[^] # Intégration à Openoffice.org
Posté par bobert . Évalué à 4.
Pour une intégration complète, on n'y est pas encore... mais il est déjà parfaitement possible de gérer des données stockées dans une base SQLite via Openoffice.org, à la Access. Voir le document suivant, rédigé par Yves Chaufour de l'équipe francophone de doc de OOo:
Yves Chaufour (Mai 2004) - "Comment utiliser une base de données SQLite avec OOo" - http://fr.openoffice.org/Documentation/How-to/Bdd/08SQLite.pdf(...)
# SQLite vs MS Access
Posté par supergab . Évalué à 1.
N'étant pas un connaisseur des base de données, je peux très bien me tromper. MS Access n'utilise pas de serveur et stocke une base de données dans un seul fichier comme SQLite.
Quelqu'un peut me dire si SQLite est meilleur que MS Access (d'un point de vue technique) et pourquoi?
[^] # Re: SQLite vs MS Access
Posté par Christophe Renard . Évalué à 2.
Le SQL de MsAcces est un chouia particulier car il melange sa syntaxe à celle du Basic ce qui peut etre énervant (par exemple, le caractère de troncature est * et non %, les caractères de délimitation de nom de champs ou de table sont [ et ] au lieu de "...
Bref, SQLite est un peut plus orthodoxe.
Par contre MsAccess offre un moteur de gestion de formulaire, de rapports et un environnement de développement, alors que SQLite est concu pour s'intégrer dans des applis tierces.
A mon avis SQLite serai un trés bonne base pour construire un concurent d'Access (qui à ma connaissance n'existe pas dans le monde libre), mais n'est pas aujourd'hui tout à fait comparable.
[^] # Re: SQLite vs MS Access
Posté par bobert . Évalué à 2.
Il y a bien Kexi [1],[2], mais on est effectivement encore loin du compte..
[1] http://www.koffice.org/kexi/(...)
[2] http://www.kexi-project.org/(...)
# BerkeleyDB ?
Posté par karteum59 . Évalué à 4.
D'ailleurs, je serais curieux de voir ce que pourrait donner la comparaison SQLite vs {BerkeleyDB + frontend SQL "bien écrit"} niveau benchmarks... ça au moins ce serait comparable (contrairement à du "SQlite vs MySQL" de base, qui est un peu absurde vu que MySQL est un serveur !).
N.B.: J'ai vu que MySQL disposait aussi d'un mode "bibliothèque", dans lequel on peut se passer de serveur (MySQL devient simplement une bibliothèque à linker, comme SQLite). Si on veut comparer les performances entre les 2 il faut utiliser MySQL de cette façons... Qqun sait ce que ça donne ?
[^] # Re: BerkeleyDB ?
Posté par Christophe Renard . Évalué à 2.
Pour le mode lib de MySQL .... interessant a voir.
En tout cas un des interets de SQLite c'est que c'est tout petit a linker.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.