Tout à fait d'accord : http://www.conjugaison-verbe.net/ver...sent-imperatif
Oui, j'ai déjà utilisé SQLite mais je ne m'en sers plus
Oui, j'ai déjà utilisé SQLite et je n'utilise rien d'autre
Oui, j'ai déjà utilisé SQLite, et je m'en sers par occasion
Non, mais j'envisage de le faire
Non et je n'envisage pas de le faire
Je n'ai pas d'avis sur la question
Tout à fait d'accord : http://www.conjugaison-verbe.net/ver...sent-imperatif
Oui enfin SQL CE, pour l'avoir utilisé assez intensivement, c'est un peu de la m***e. Ça n'a de SQL Server que le nom, et à peu près aucune des features. De plus il n'y a toujours pas de version compatible WinRT/UWP, donc ce n'est plus utilisable pour des applis mobiles modernes. Même Microsoft recommande SQLite pour ces applis. Et même Erik Ejlskov Jensen, qui est un peu LE gourou de SQL CE, s'est fendu d'un post pour expliquer comment utiliser SQLite dans une appli WinRT: http://erikej.blogspot.fr/2012/08/ge...n-windows.html
Pour ce qui est de la montée en charge, c'est vrai, mais ce n'est pas prévu pour. Si tu fais une appli mobile, tu n'as certainement pas besoin de monter en charge. Pour une appli desktop, ça dépend, mais bien souvent SQLite est amplement suffisant. Si tu fais une appli web qui va potentiellement avoir beaucoup d'utilisateurs, là tu prendras un SQL Server, PostgreSQL ou autre SGBD serveur.
En fait, je parle de l'aspect concurrentiel parce que je me suis fait mordre par le Python en testant localement sous sqlite un site web qui par ailleurs tourne sous postgresql et qui faisait des écritures en parallèle. On se trouvait avec un bogue qui nous laissait perplexes avant de comprendre qu'il fallait juste réduire le nombre de workers à 1 qd on avait affaire à sqlite.
Sqlite par ailleurs rend de fiers services! Un petit bijou de lib!
Daniel
LocalDB est vraiment une solution assez puissante je trouve, avec des éléments que j'apprécie : les procédures stockées , les outils comme bcp, les triggers...
Le gros problème est que cela nécessite une installation... Ce n'est pas aussi léger que quelques dll à embarquer avec un exécutable...
Dommage; je rêve d'une soluce LocalDB sans avoir une installation à faire.
Je sais pas s'ils mentent, mais sur leur site :
400k d'utilisateurs par jours c'est pas mal quand mêmeThe SQLite website (https://www.sqlite.org/) uses SQLite itself, of course, and as of this writing (2015) it handles about 400K to 500K HTTP requests per day, about 15-20% of which are dynamic pages touching the database. Each dynamic page does roughly 200 SQL statements. This setup runs on a single VM that shares a physical server with 23 others and yet still keeps the load average below 0.1 most of the time
Je sais pas s'ils mentent, mais sur leur site :
400k d'utilisateurs par jours c'est pas mal quand mêmeThe SQLite website (https://www.sqlite.org/) uses SQLite itself, of course, and as of this writing (2015) it handles about 400K to 500K HTTP requests per day, about 15-20% of which are dynamic pages touching the database. Each dynamic page does roughly 200 SQL statements. This setup runs on a single VM that shares a physical server with 23 others and yet still keeps the load average below 0.1 most of the time
Peut être mais la sa sent la vitrine technologique inutilisable en condition réel.
SQlite n'est pas fait pour tourner sur 23 serveurs. Il y'a des solutions plus simple et plus adaptés.
SQlite peut gérer 500K utilisateurs, il suffit de bien répartir ces 500K utilisateurs en plusieurs fichier, en fonction du pseudo par exemple.
Par exemple, un utilisateur ayant comme pseudo sazearte, pourrait ranger dans le fichier se6.sqlite3, ce fichier contiendrais tous les utilisateurs ayant comme un pseudos commençant par s, se terminant par e et ayant 6 caractères.
Si un jour on souhaite modifier la structure d'une table, il suffit de faire un script qui modifie tous les fichiers.
C'est du vécu ce bricolage, j'ai du une fois crée un hack similaire mais avec un SGBD propriétaire/fait maison appartenant à une entreprise (c'était de la merde) qui utilisait des fichiers xml. Le développeur qui avait pondue cette hérésie ne devait sans doute pas connaitre de SGBD. Quand je suis arrivé la BDD c'était un gros fichier xml de 6Go, et a moins de tous recoder, j'ai du modifier le fichier xml de 6Go en plusieurs fichier xml de 200mo.
Certes, mais :
1. 400k requêtes (et non utilisateurs) par jour, ça fait moins de 5 requêtes par seconde... pas vraiment ce qu'on peut appeler une très grosse charge. A comparer avec Twitter ou Facebook...
2. Seulement 15 à 20% de ces requêtes tapent sur la base de données. Soit moins d'une requête par seconde sur la DB...
Je ne dis pas ça pour critiquer SQLite (j'adore ce SGBD), mais c'est vraiment pas fait pour les grosses charges, et encore moins pour des applications multi-user.
de plus si c'est une base en mémoire uniquement ...
Attention ce n'est pas ce qui est dit: le site de SQLite est installé sur une machine virtuelle qui est sur une machine physique qui en a 23 autres (machines virtuelles).
Concernant SQLite, j'apprécie sa facilité de déploiement/installation pour des petites applis web, spécialement quand on fait un dev pour des non informaticiens qui auront besoin d'installer l'appli (sans parler des applis mobiles). Sur les perfs je n'ai pas poussé assez loin pour savoir où sont les limites, mais je me doute qu'on est derrière un Postgresql (ou même MySQL) dès qu'on veut une utilisation plus intensive.
Pour embarquer une base dans une application standalone en java, J'utilise surtout Hsql.
Pour l'instant je la trouve suffisante.
Mais j'envisageais déjà de tester H2 et Sqlite.
Elles fonctionnent toutes en mémoire
Je vous suis à 100% sur le point noir que représente cette incapacité de monté en charge de SQLite.
C'est sans importance dans certaines utilisations, mais plus problématique dans d'autres et mérite d'être méditée.
Le monde Microsoft offre effectivement une évolutivité maximale ; une documentation solide et de nombreux exemples.
Mais 3 bémols :
- même en LocalDB, MS-SQL est plus lourd qu'une simple DLL à copier dans le dossier de l'application.
- dès qu'on tape dans une limite (10Go + 1 octet), il faut passer à la licence du dessus et là c'est plus du tout gratuit. Parfois, il faut même changer de Windows car la licence du MS-SQL dont ont a besoin ne tourne pas sur la version de Windows actuel (vécu sur Web Edition qui n'existe plus, je crois). On comprend qu'une base de 10 Mo et une base de 11Go ne coute pas le même prix, mais c'est le passage de la limite qui est brutal.
- univers Microsoft uniquement.
C'est pourquoi je préfère Firebird déjà cité.
Je ne veux en aucun cas, le comparer à MS-SQL en tant que SGBD, mais comme alternative à SQLite.
Firebird :
- est très léger et peut se limiter à quelques fichiers copié dans le dossier de l'appli (une DLL en version 3).
- Reste gratuit et avec une licence très souple quelque soit la charge.
- Comme SQLite, tourne sur de nombreux systèmes (Windows, Linux, Mac OS)
Le seul point faible de Firebird par rapport à SQLite reste le nombre de plate-formes où il est disponible.
Même s'il existe un build Android de Firebird, SQLite reste le champion pour ce qui est du nombre de platte-formes supportés.
Pour la limite de 10 Go, il y a quelques astuces :
1) FILESTREAM et FILETTRABLE ne sont pas concernés par ces limites
2) comme tu peut faire jusqu'à 32760 bases, il suffit de partitionner les grosses tables et de faire des vues (UNION ALL) qui rassemble les données des différentes bases. Si tu veut les mettre à jour, déclencheur INSTEAD OF...
3) La variation la plus fluide se trouve dans Azure !
A +
J'ai été séduit par la facilité que j'ai eu à compiler sa lib en n'incluant que 2 fichiers sur codeblocks, sqlite est génial
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager