N'est-ce pas un peu dangereux de partir sur des solutions commerciale ? Genre : au début c'est gratuit/pas cher. Donc, tu le prends et tu lies ton design/ton code à cette solution.
Plus tard, ça devient trop cher... mais tu te retrouves pieds et poings liés...
Alors, oui, tes craintes sont justifiées, et effectivement, Parse est une solution qui devient chère quand on a beaucoup d'utilisateurs.
Mais c'est très rapide à mettre en place au niveau du code. Alors, je préfèrerais partir sur une solution facile, quitte à changer plus tard si besoin. Parce que dans la réalité, on a du mal à avoir ce problème de riche qui est d'avoir beaucoup d'utilisateurs. La vérité c'est que si tu parviens déjà à faire 10 000 téléchargements, c'est pas mal.
"En informatique un système de gestion de base de données (abr. SGBD) est un logiciel système destiné à stocker et à partager des informations dans une base de données, en garantissant la qualité, la pérennité et la confidentialité des informations, tout en cachant la complexité des opérations." " Wikipedia
En aucun cas, la spécificité du partage inter-application ou inter-système n'est un fondamental de la chose. Un NSUserDefault qui va partager l'accès à un XML entre différent thread en s'occupant de garantir l'atomicité des requêtes ainsi que la gestion du fichier sur disque est en soit un SGBD, même s'il ne gère pas de partie relationnelle ou de langage SQL. ça reste un SGBD de type key value store.
Nous n'avons pas la même interprétation de "logiciel système".
Donc une bibliothèque est un logiciel système et un fichier de données est une base de données. Il n'y a rien à ajouter.
Pour ma part je considère que SQLite3 ne permet pas d'assurer la confidentialité des données, ni n'importe quelle bibliothèque d'accès à des fichiers structurés (XML, Plist, ...). On pourrait discuter sans fin des aspects "partage des données", "qualité des données", ...
Chaque définition fait appel à d'autres définitions, etc. Et du coup on peut interpréter toute définition.
Je pense que des définitions qui sont toutes équivalentes sont inutiles. Je préfère les interprétations qui permettent de bien identifier les différents aspects des choses.
Peut-être considères-tu qu'à partir du moment où il y a des tables, des colonnes et du SQL c'est une base de données ? Mais c'est une autre définition que celle de Wikipedia. Cette définition me paraà®t trop limitative car elle exclut les SGBD non relationnels. À la rigueur j'admettrait qu'on dise qu'un fichier SQLite3 est une BDR, mais ce n'est pas un SGBD (ce qui est embêtant car implicitement toute BdD est sous un SGBD).
Je pense que lorsque Benjo' parle de "Base de données en ligne" il recherche plus un SGBD qu'un fichier BDR.
Nous n'avons pas la même interprétation de "logiciel système".
Donc une bibliothèque est un logiciel système et un fichier de données est une base de données. Il n'y a rien à ajouter.
Pour ma part je considère que SQLite3 ne permet pas d'assurer la confidentialité des données, ni n'importe quelle bibliothèque d'accès à des fichiers structurés (XML, Plist, ...). On pourrait discuter sans fin des aspects "partage des données", "qualité des données", ...
Chaque définition fait appel à d'autres définitions, etc. Et du coup on peut interpréter toute définition.
Je pense que des définitions qui sont toutes équivalentes sont inutiles. Je préfère les interprétations qui permettent de bien identifier les différents aspects des choses.
Peut-être considères-tu qu'à partir du moment où il y a des tables, des colonnes et du SQL c'est une base de données ? Mais c'est une autre définition que celle de Wikipedia. Cette définition me paraà®t trop limitative car elle exclut les SGBD non relationnels. À la rigueur j'admettrait qu'on dise qu'un fichier SQLite3 est une BDR, mais ce n'est pas un SGBD (ce qui est embêtant car implicitement toute BdD est sous un SGBD).
Je pense que lorsque Benjo' parle de "Base de données en ligne" il recherche plus un SGBD qu'un fichier BDR.
Une BDD n'a pas besoin de SQL, une base de donnée se définie bien toute seule, c'est un silo à donnée. Et SQLite est un système qui permet de gérer un des types de forma de silo. La définition de Wikipedia est très bien sur le sujet.
Sinon je ne comprend pas la remarque sur la confidentialité que ne gère pas SQLite, le chiffrement des données n'est pas un prérequis des SGBD hein...
Dans tous les cas, SQLite n'est pas du tout adapté pour des accès concurrentiels (certes il y a quelques fonctions de libsqlite qui permettent de verrouiller les accès, mais bon c'est pas l'idéal, ça verrouille tout le fichier, bloquant tout, c'est pas de la vrai gestion d'accès concurrenciel comme le ferait une base MySQL ou PostGre ou Oracle).
Quand tu mets ta base sur un serveur et donc que, contrairement à une base locale limitée à ton ordi, là ta base va être attaquée par plein de requêtes (selon la popularité de ton appli) du web qui vont être souvent simultanées, et donc que là les accès concurrentiels seront potentiellement nombreux et la norme, et pas une petite exception de temps en temps, là SQLite n'est pas du tout adapté (et va pas arrêter de verrouiller tout le fichier pour rien). C'est pas pensé pour.
We are aware of no other embedded SQL database engine that supports as much concurrency as SQLite. SQLite allows multiple processes to have the database file open at once, and for multiple processes to read the database at once. When any process wants to write, it must lock the entire database file for the duration of its update. But that normally only takes a few milliseconds. Other processes just wait on the writer to finish then continue about their business. Other embedded SQL database engines typically only allow a single process to connect to the database at once.
However, client/server database engines (such as PostgreSQL, MySQL, or Oracle) usually support a higher level of concurrency and allow multiple processes to be writing to the same database at the same time. This is possible in a client/server database because there is always a single well-controlled server process available to coordinate access. If your application has a need for a lot of concurrency, then you should consider using a client/server database. But experience suggests that most applications need much less concurrency than their designers imagine.
En fait il y a de nombreux cas où SQLite pourrait faire l'affaire côté serveur.
La vraie limite, c'est un grand nombre d'écritures concurrentes.
L'histoire des techno web fait que mysql est disponible partout donc et comme mysql gère à peu près bien tous les cas, il est inutile de se prendre la tête avec SQLite.
En fait il y a de nombreux cas où SQLite pourrait faire l'affaire côté serveur.
La vraie limite, c'est un grand nombre d'écritures concurrentes.
L'histoire des techno web fait que mysql est disponible partout donc et comme mysql gère à peu près bien tous les cas, il est inutile de se prendre la tête avec SQLite.
Leur commentaire est tout à fait vrai. Même si en exagérant, l'écriture dure une seconde, il y a extrêmement peut de service qui vont ressentir la latence, car tout simplement à nos volumes d'utilisateur nous n'avons pas un usage des bases à 100% du temps comme Google ou Facebook. La latence d'Internet de manière générale va masquer les éventuelles congestion de la base.
Et clairement, pour qu'il y ait congestion de la base il faut qu'une écriture ait lieu en même temps qu'une autre action. Vous imaginez la probabilité de la chose ?
C'est éventuellement possible, donc il y a des mécanisme de protection, mais avant que ça arrive suffisamment souvent pour que cela nécessite une optimisation, il y a de la marge.
La plupart des services web grand public l'ont bien compris et proposent aujourd'hui pour plus de simplicité un stockage en base SQLite voir même en file system.
Réponses
Mais c'est très rapide à mettre en place au niveau du code. Alors, je préfèrerais partir sur une solution facile, quitte à changer plus tard si besoin. Parce que dans la réalité, on a du mal à avoir ce problème de riche qui est d'avoir beaucoup d'utilisateurs. La vérité c'est que si tu parviens déjà à faire 10 000 téléchargements, c'est pas mal.
"En informatique un système de gestion de base de données (abr. SGBD) est un logiciel système destiné à stocker et à partager des informations dans une base de données, en garantissant la qualité, la pérennité et la confidentialité des informations, tout en cachant la complexité des opérations." " Wikipedia
En aucun cas, la spécificité du partage inter-application ou inter-système n'est un fondamental de la chose. Un NSUserDefault qui va partager l'accès à un XML entre différent thread en s'occupant de garantir l'atomicité des requêtes ainsi que la gestion du fichier sur disque est en soit un SGBD, même s'il ne gère pas de partie relationnelle ou de langage SQL. ça reste un SGBD de type key value store.
OK.
Nous n'avons pas la même interprétation de "logiciel système".
Donc une bibliothèque est un logiciel système et un fichier de données est une base de données. Il n'y a rien à ajouter.
Pour ma part je considère que SQLite3 ne permet pas d'assurer la confidentialité des données, ni n'importe quelle bibliothèque d'accès à des fichiers structurés (XML, Plist, ...). On pourrait discuter sans fin des aspects "partage des données", "qualité des données", ...
Chaque définition fait appel à d'autres définitions, etc. Et du coup on peut interpréter toute définition.
Je pense que des définitions qui sont toutes équivalentes sont inutiles. Je préfère les interprétations qui permettent de bien identifier les différents aspects des choses.
Peut-être considères-tu qu'à partir du moment où il y a des tables, des colonnes et du SQL c'est une base de données ? Mais c'est une autre définition que celle de Wikipedia. Cette définition me paraà®t trop limitative car elle exclut les SGBD non relationnels. À la rigueur j'admettrait qu'on dise qu'un fichier SQLite3 est une BDR, mais ce n'est pas un SGBD (ce qui est embêtant car implicitement toute BdD est sous un SGBD).
Je pense que lorsque Benjo' parle de "Base de données en ligne" il recherche plus un SGBD qu'un fichier BDR.
Une BDD n'a pas besoin de SQL, une base de donnée se définie bien toute seule, c'est un silo à donnée. Et SQLite est un système qui permet de gérer un des types de forma de silo. La définition de Wikipedia est très bien sur le sujet.
Sinon je ne comprend pas la remarque sur la confidentialité que ne gère pas SQLite, le chiffrement des données n'est pas un prérequis des SGBD hein...
Dans tous les cas, SQLite n'est pas du tout adapté pour des accès concurrentiels (certes il y a quelques fonctions de libsqlite qui permettent de verrouiller les accès, mais bon c'est pas l'idéal, ça verrouille tout le fichier, bloquant tout, c'est pas de la vrai gestion d'accès concurrenciel comme le ferait une base MySQL ou PostGre ou Oracle).
Quand tu mets ta base sur un serveur et donc que, contrairement à une base locale limitée à ton ordi, là ta base va être attaquée par plein de requêtes (selon la popularité de ton appli) du web qui vont être souvent simultanées, et donc que là les accès concurrentiels seront potentiellement nombreux et la norme, et pas une petite exception de temps en temps, là SQLite n'est pas du tout adapté (et va pas arrêter de verrouiller tout le fichier pour rien). C'est pas pensé pour.
Vu sur le site de SQLite
En fait il y a de nombreux cas où SQLite pourrait faire l'affaire côté serveur.
La vraie limite, c'est un grand nombre d'écritures concurrentes.
L'histoire des techno web fait que mysql est disponible partout donc et comme mysql gère à peu près bien tous les cas, il est inutile de se prendre la tête avec SQLite.
Leur commentaire est tout à fait vrai. Même si en exagérant, l'écriture dure une seconde, il y a extrêmement peut de service qui vont ressentir la latence, car tout simplement à nos volumes d'utilisateur nous n'avons pas un usage des bases à 100% du temps comme Google ou Facebook. La latence d'Internet de manière générale va masquer les éventuelles congestion de la base.
Et clairement, pour qu'il y ait congestion de la base il faut qu'une écriture ait lieu en même temps qu'une autre action. Vous imaginez la probabilité de la chose ?
C'est éventuellement possible, donc il y a des mécanisme de protection, mais avant que ça arrive suffisamment souvent pour que cela nécessite une optimisation, il y a de la marge.
La plupart des services web grand public l'ont bien compris et proposent aujourd'hui pour plus de simplicité un stockage en base SQLite voir même en file system.