Choix d'un système de base de donnée en fonction de l'usage

[djes]

Ce n'est peut-être pas si bête de parler de json depuis que le NoSQL est devenu plus qu'une mode, une nouvelle façon d'organiser les données, qui peut reposer sur de nombreux fichiers simples, gérés par le système, et donc plus rapides à ouvrir/mettre à jour/fermer qu'une grosse base verrouillée, surtout quand on n'a pas de serveur à disposition.

[Ollivier]

ça n'engage que moi.

On ne peut pas meilleur verrouillage.

[G-Rom]

Ce n'est peut-être pas si bête de parler de json depuis que le NoSQL est devenu plus qu'une mode, une nouvelle façon d'organiser les données, qui peut reposer sur de nombreux fichiers simples, gérés par le système, et donc plus rapides à ouvrir/mettre à jour/fermer qu'une grosse base verrouillée, surtout quand on n'a pas de serveur à disposition.

Jamais vu de serveurs se servir de milliers de fichier json en lieu & place d'une base sql. et puis le nosql est avant tout une réponse à des problèmes de charge que pose une base énorme.

[microdevweb]

Il est évident que celui qui veut peux toujours d'amuser avec des fichier Json,text ou autre et même à concevoir lui même ses accès mécanisme de filtre et de recherche.

Se serais un peut comme faire son propre mécanisme de listes chaînées alors que cela existe dans la bibliothèque de PureBasic.

Moi personnellement je ne vais pas cherché à réinventer la roue et utiliserais un moteur Sql adéquat au type de base de données.

Maintenant si je crée un soft qui travaille en mémoire et offre une possibilité de sauvegarde je me tournerais vers Json. Pour une gestion de données tel que les préférences se sera Json (que je préfère au pref de Pb).

Donc comme indiqué dans le titre de ce post, le choix dépend de l'usage et je penses qu'avant de poser la moindre ligne de code il est important de déterminer le type de gestion de données que l'on va gérer et comment parce que changer en cour de route ben il faudra tout modifier surtout si le code n'a pas été étudié modulaire.

D'ou mon conseil, ne jamais passer les requêtes directement depuis le code, mais préféré le passage par des fonctions prévuent à cette effet. Ainsi si par exemple une base local (type Sqlite ) doit passé en réseau (type postgresql) seul le code des dites fonctions devra être modifié

[Marc56]

Pour une gestion de données tel que les préférences se sera Json (que je préfère au pref de Pb)

Ce qui est nouveau ou pire, à la mode, n'est pas forcément meilleur, il faut voir les avantages/inconvénients des deux formats:

Format JSON
- Lecture et écriture: tout le fichier à chaque fois
- Edition manuelle: difficile même sur un fichier formaté
- Manipulation en mémoire: compliquée (notion d'objet)

Format INI (fichiers preferences)
- Pas d'obligation de lire/écrire tout le fichier à chaque accès disque
- Edition manuelle: facile
- Lecture et écriture possible et rapide par n'importe quel programme (batch, findstr etc)
- Structure simple à utiliser/lire/comprendre: ([groupe] facultatif) et clé=valeur
- De mauvaises clés n'empêchent pas la lecture du reste du fichier
- Pas d'obligation de définir le type de données (texte ou numérique)

JSON à l'avantage si on veut lire/écrire un tas de variables en une seule fois
INI est préférable quand on veut ne lire/écrire que certaines valeurs

[microdevweb]

Marc56 la raison est assez simple, je développes de façon modulaire et stocke toutes les données générales tel que les préférences du projet dans une structure. Avec Json je ne les lit qu'au lancement du programme. Cela peut se faire automatiquement contrairement au pref de Pb

[djes]

Ce n'est peut-être pas si bête de parler de json depuis que le NoSQL est devenu plus qu'une mode, une nouvelle façon d'organiser les données, qui peut reposer sur de nombreux fichiers simples, gérés par le système, et donc plus rapides à ouvrir/mettre à jour/fermer qu'une grosse base verrouillée, surtout quand on n'a pas de serveur à disposition.

Jamais vu de serveurs se servir de milliers de fichier json en lieu & place d'une base sql. et puis le nosql est avant tout une réponse à des problèmes de charge que pose une base énorme.

Pourquoi parler de milliers de fichiers ? Le SQL est un langage. Il définit un mode d'organisation des données. Dans beaucoup de cas, sa complexité est inutile, voire source de lenteurs. Aussi, même s'il est vrai qu'il a été imaginé pour pallier la lenteur des requêtes SQL complexes, NoSQL remet aussi en question cette pensée unique qui veut que base de données = SQL. Aujourd'hui, avec les capacités de stockage dont on dispose et leurs temps d'accès, ça peut valoir le coup de s'en passer. Il suffit de repenser l'organisation de ses données, et plutôt que d'avoir 36 tables avec des clés partout, quelques tables bien complètes qui répondent aux besoins.
Ceci dit, je fais juste un peu mon troll car je déteste l'immobilisme.

[G-Rom]

Pourquoi parler de milliers de fichiers ?

..., une nouvelle façon d'organiser les données, qui peut reposer sur de nombreux fichiers simples, ...

[djes]

Euh ! Plusieurs, ça commence à deux. Dans un MCD moyennement complexe, on compte rarement plusieurs centaines de tables. Alors parler de milliers de fichiers, c'est très différent !

[boby]

Le NoSQL pourquoi pas, mais est-ce que ça ne fait pas perdre les fonctions de trie/recherche plutôt puissantes appartenant au SQL ? C'est quand même (je trouve) vachement pratique d'avoir tout ce système déjà mis en place et quand même vraiment bien fonctionnel.

Moi personnellement j'ai tendance à bourrer le SQL, même sur une appli avec très peux de donnée je m'oriente facilement sur du SQLite pour profiter de ces fonctions justement.

[djes]

Le NoSQL pourquoi pas, mais est-ce que ça ne fait pas perdre les fonctions de trie/recherche plutôt puissantes appartenant au SQL ? C'est quand même (je trouve) vachement pratique d'avoir tout ce système déjà mis en place et quand même vraiment bien fonctionnel.

Moi personnellement j'ai tendance à bourrer le SQL, même sur une appli avec très peux de donnée je m'oriente facilement sur du SQLite pour profiter de ces fonctions justement.

Mon troll fait son effet. Effectivement, le SQL est pratique, et quand on commence à avoir l'habitude, on voudrait l'utiliser partout. Mais cela n'empêche qu'il faut quand même apporter une réponse adaptée à une situation donnée. Certains ont tendance à toujours vouloir utiliser la grosse artillerie !

Ici, il n'y a quasiment jamais de projets d'applications nécessitant réellement une base de données sur serveur. Pour des sites web, c'est une autre histoire, puisque les serveurs BD vont décharger les serveurs WWW, et améliorer le temps de réponse global.

Alors oui, le SQL, c'est pratique, comme les expressions régulières. SQLite est idéal pour certains projets. Mais il y a quand même beaucoup de situations (l'équivalent d'une dizaine de tables, quelques milliers d'enregistrements, il faut ajuster en fonction de la capacité mémoire de l'ordi) où on peut s'en passer et gérer soi-même en direct les recherches et la gestion des données. C'est beaucoup plus rapide, moins prise de tête, et surtout, beaucoup plus résilient que de compter sur des libs externes. Ca peut être aussi très utile quand on gère d'énormes quantités de données et qu'il faut absolument garder la main sur tout et gagner en efficacité. C'est le plaisir du programmeur de chercher et de trouver la meilleure solution, et personnellement, je me méfie toujours des conseils genre doxa.

[G-Rom]

Euh ! Plusieurs, ça commence à deux. Dans un MCD moyennement complexe, on compte rarement plusieurs centaines de tables. Alors parler de milliers de fichiers, c'est très différent !

Comme tu n'est pas clair, j'avais compris que tu parlais de .json pour chaque enregistrement. dans le cadre d'un forum par exemple, on dépasse le millier sans problème.
ceci dit, cette méthode est valable pour l'auteur du topic, pas esthétique ni vraiment safe, mais valable tout de même.

Certains ont tendance à toujours vouloir utiliser la grosse artillerie !

C'est vrai , dans son cas, j'utiliserais ni le .json, ni sql. mais mon propre format qui colle à mes besoins, facile à mettre en place, pas de prise de tête.

[Marc56]

Le NoSQL pourquoi pas, mais est-ce que ça ne fait pas perdre les fonctions de trie/recherche plutôt puissantes appartenant au SQL ? C'est quand même (je trouve) vachement pratique d'avoir tout ce système déjà mis en place et quand même vraiment bien fonctionnel.

Moi personnellement j'ai tendance à bourrer le SQL, même sur une appli avec très peux de donnée je m'oriente facilement sur du SQLite pour profiter de ces fonctions justement.

+1
C'est aussi ce que font de plus en plus d'applications et non des moindres comme FireFox: déléguer la gestion des données (ici le bookmark) à SQLite.
Ce dernier est à la fois léger, solide, gratuit, fiable. Les utilisateurs qui perdent le contenu de leur table on le plus souvent fait de fausse manip au niveau application.

Gérer ses données avec un format interne c'est (c'était) bien quand on a peu de données, mais ça prend du temps, de la place (si on fait des fichiers avec des champs de longueur fixe) et il faut assurer soi-même les tri, la cohérence, bref souvent une perte de temps considérable sur le reste du développement.
Ça reste un bon exercice de style pour comprendre les FileSeek, mais si on a des champs de longueur variables ou des blobs, ça se complique vite alors que SQLite fait tout ça en à peine moins de 300 ko.

Les bases NoSQL sont pour l'instant l'usage de très grosses entreprises, quoi que beaucoup les utilisent déjà depuis des années sans le savoir (ie: Berkeley DB pour les annuairees LDAP) et de toutes façons NoSQL ne signifiant pas No SQL mais Not Only SQL, les bases SQL sont des bases NoSQL puisque ce dernier définit 4 type de bases (Orientées Colonnes (=SQL), Lignes, Document, Graph)

37 ans (depuis mon ZX 81) que je faisais du NoSQL sans le savoir

[G-Rom]

Gérer ses données avec un format interne c'est (c'était) bien quand on a peu de données, mais ça prend du temps, de la place (si on fait des fichiers avec des champs de longueur fixe) et il faut assurer soi-même les tri, la cohérence, bref souvent une perte de temps considérable sur le reste du développement.
Ça reste un bon exercice de style pour comprendre les FileSeek, mais si on a des champs de longueur variables ou des blobs, ça se complique vite alors que SQLite fait tout ça en à peine moins de 300 ko.

-1

C'est faux. c'est facile de géré son propre format. utilisé sql pour de petite appli c'est de la fainéantise. Sérialisée des données c'est la base de la programmation.
cela me fait pensé à une lib que j'ai codé : https://www.purebasic.fr/french/viewtop ... it=tornado
à l'intérieur de ce code il y a "des packets" , ou l'on peut aisément "poussé" n'importe quel type de donnée dans le paquet à coup de push , sans ce soucier de la taille.
puis des coups de pop pour lire le paquet, on peut facilement avec writedata() écrire le dit paquet sur le disque ensuite.
https://pastebin.com/0RKUfUVt , c'est un exemple parmi tant d'autres.

[Marc56]

La qualité première d'un bon codeur c'est la fainéantise. Si on veut (aime) programmer au raz des parquettes (bas niveau), à coup de writedata, readdata, fileseek, on fait du C ou de l'assembleur, pas du Basic.

L'avantage du Basic, et PB le fait très bien c'est de soulager l'utilisateur de la partie casse-pied et source d'erreurs pour qu'il puisse se concentrer sur le reste du programme d'où l'intégration de libs pour les "formats" de stockage de données INI, XML, JSON, SQLite, PostregSQL. Choix excellents de la part de l'équipe PB.

On peut bien-sur gérer ses données soi-même, c'est un exercice utile pour comprendre comment ça marche, mais au final, on finit... par créer une lib...

On remplace quelque chose qui a déjà été longuement débuggué par quelques milliers de personnes par un truc personnel potentiellement buggé (car peu d'utilisateurs). Où est l'intérêt ? à part éducatif et auto satisfaction (ça je le concède, j'adore aussi réinventer la roue, mais je ne le fait pas quand je code pour d'autres)

La chose la plus importante en matière de base de données est d'assurer la pérennité de celles-ci, donc pouvoir les traiter avec des outils tiers. On doit pouvoir manipuler les données sans une documentation sur la structure de la base.