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

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

[Ollivier]

Bonjour Marc56,

je remercie beaucoup le soin de pertinence de tes messages, pertinence à ne pas remettre en cause.

Le diable est dans les détails. Là, tu appuies le choix du traitement de BDD sur le fait ou non de s'épargner le séquençage. Or, pour quelqu'un qui souhaiterait traiter des données confidentielles, la qualité de certains programmeurs c'est de joindre l'utile à l'agréable. C'est gentil de dire que la fainéantise est une qualité. Mais, en bout de chaîne, ce sont des ouvriers ou des particuliers qui se prennent les "pots cassés" et une batterie d'ingénieurs ne peut scruter tout ça, sinon on serait dans un monde parfait.

Aussi, le séquençage, c'est du Lego. C'est un vrai délire de gamin qui s'exécute un milliard de fois plus vite que les petits doigts des deux mains.

Je trouve aussi que l'erreur d'exclure le C et l'ASM d'une zone "Basic", c'est conseiller de looper un coche.

En C, tu as des libs par milliers, jamais je n'y mettrai les pieds. Et pourtant pour certaines, ça a été un brassage de pognon pour les concevoir et adouber leur gloire.

Si quelqu'un me dit << Voici les 200 000 références et leurs caractéristiques. >> là, le choix de ne pas réinventer la roue s'impose.

Le besoin final dirige le choix (niveau de confidentialité et type de flux : création pure, importation ou les deux).

[boby]

utilisé sql pour de petite appli c'est de la fainéantise.

Le SQL est un langage de programmation comme un autre, en quoi choisir un outil fonctionnel, optimisé, léger et répondant à tous nos besoin est de la fainéantise ?
On peut tout autant dire qu'utiliser pure basic est de la fainéantise dans ce cas la... Tu utilise un langage avec des fonctions toutes faites alors que tu pourrais le faire toi même.

Je n'arrive pas vraiment à voir ce qu'il y a de gênant à utiliser un code testé et approuvé depuis de belles années par une armée de développeur bien plus compétant que moi, donc qui offre un service bien plus efficace que ce que je serais capable de faire.

[Marc56]

Je trouve aussi que l'erreur d'exclure le C et l'ASM d'une zone "Basic", c'est conseiller de looper un coche.

Oui,
J'ai toujours comme un regret ne ne jamais avoir fait d'ASM, puis je reconsidère que j'ai toujours pu résoudre mes problèmes sans.

Le C j'en ai fait, j'en fait encore, je l'utilise surtout au travers de Perl, mais c'est quelque chose que je ne conseillerais pas à quelqu'un qui n'a jamais programmé. C'est un pur outil de travail, mais pas bon pour apprendre, car la syntaxe n'est pas "logique". C'est utile pour faire de la programmation système, mais lourd pour le reste.

Pour les bases de codage, par exemple niveau gestion fichier sur disque, il est plus utile de connaitre les deux types de fichier existants (binaire et texte) et les deux modes d'accès possibles (séquentiel ou direct). Avec ça on comprend l'essentiel quelque soit le langage utilisé ensuite.

Stupéfaction de voir des jeunes formés ne pas connaitre ça et se précipiter tout de suite à la recherche d'une lib dès qu'on leur parle de fichier de données. Et s'il n'y a pas une lib pour le type de fichier demandé, alors c'est que ce n'est pas possible :-/ (vécu)

Cela dit, je n'ai toujours fait que des programmes de gestion (principalement du middleware) et de petits outils. Si j'avais dû faire du traitement d'image ou de l'algorithmique pure, j'aurai fais de l'ASM.

La seule fois ou j'ai approché l'ASM, enfin taquiné les registres, c'était à l'époque de la programmation DOS en (Borland) TP et TC++ quand on voulait utiliser la souris, il fallait le faire directement avec l'interruption 33h, mais c'était facile de remplir et lire AX, BX, DX pour lui faire faire ce qu'on veut.

Donc en ayant pratiqué pas mal de truc, j'apprécie d'autant plus les choix et possibilités de PB et les choix qui sont fait entre abstraction (encapsulation des API, et de celles qui vont bien) et possibilité d'adresser la ram directement (peek, poke)

[falsam]

suite a la confrontation (commentaires supprimés) orduriere entre grom et omega le sujet est clos durant le week-end.

Les commentaires qui n'ont aucun rapports avec le sujet ont été supprimés

[Fred]

Pas la peine de déverouiller un topic précédement vérouillé. A G-Rom et Omega (et les autres tant qu'à faire) -> la prochaine fois qu'une insulte est proférée sur ce forum, c'est le banissement sans sommation.