PureBasic

@Micoute..
Je rejoints Falsam.
Même si l'intention est bonne, ton 1er code est hors sujet et le second (conversion en module) n'est pas un exemple à suivre du fait qu'un module doit pouvoir être importé par autrui sans que cela ne puis générer de conflits. Et oui c'est censé être une série de fonctions à part entière plutôt qu'un truc autonome.

Même si les données intra modules sont censée être protégées dedans, si un utilisateur mets un dans son code (car il ne se souviendra pas forcément des constantes de ton module) je me dis que ça peut chinoiser.

Bonjour Falsam et merci pour ta proposition.
Je viens de jeter un coup d'oeil sur les fichiers Json. Je voudrais juste savoir pourquoi choisir Json (avantage par rapport à sqlite par exemple)
Merci

Parce que c'est simple, c'est un format de données ouvert donc interprété par x langages JavaScript, PHP, Perl, Python, Ruby, Java,...
Permet de stocker des données de différents types : chaînes de caractères (y compris des images en base64), nombres, tableaux (array), objets, booléens (true, false), la valeur null.
Sa structure en arborescence et sa syntaxe simple lui permet de rester très "léger" et efficace.
plus d'infos ici : https://www.alsacreations.com/article/l ... types.html

Je viens de jeter un coup d'oeil sur les fichiers Json. Je voudrais juste savoir pourquoi choisir Json (avantage par rapport à sqlite par exemple)

Savoir que comme pour les fichiers XML, les fichiers JSON au niveau disque, on lit ou écrit tout le fichier à chaque fois.

C'est logique, ce sont des flats files (fichiers plats, c'est à dire du texte brut) C'est un avantage (lisibilité) et un inconvénient: il faut "pousser" tout quand on remplace une donnée par une autre de taille différente.

De plus, si on travaille sur plusieurs enregistrements et qu'on ne sauvegarde pas à chaque modification (ou qu'on ne stocke pas les données "modifiées" dans une autre structure), si on fait une erreur sur un enregistrement on perd les autres modifications effectuées depuis à moins de recopier les données validées avant dans la structure à écrire.

Si plusieurs utilisateurs travaillent sur la même source de données, ils ont chacun une copie des données et aucune synchro de données ou alors il faut gérer un verrou en manuel.

Les fichier JSON c'est bien pour sauver un paquet de données disparates ou pour de petites bases type carnet d'adresse, mais pour quelques centaines d’enregistrements ou plus ce n'est pas adapté.

Les fichier JSON c'est bien pour sauver un paquet de données disparates ou pour de petites bases type carnet d'adresse, mais pour quelques centaines d’enregistrements ou plus ce n'est pas adapté.

J'ai besoin au moins de 3000 enregistrements (c'est le contenu de mon fichier livraison (base sqlite).

Le problème avec un fichier Json qui n'est rien d'autre qu'un fichier texte balisé, il faudra charger tous les records en mémoire. Cette opération est faite au lancement du soft donc cela ne se sentira pas.

Par contre chaque recherche va demander de parcourir toute la liste jusqu’à trouvé le bon record et si c'est dernier. Maintenant avec 3000 records cela ne devrais pas prendre trop de temps par contre avec plus.

microdevweb a écrit :Par contre chaque recherche va demander de parcourir toute la liste jusqu’à trouvé le bon record

Non pas du tout.

Un fichier JSON contenant une suite d'enregistrements est obligatoirement associé à une liste chaînée ou une map. Tu auras compris que associée à une map la recherche est ultra rapide.

falsam a écrit : Un fichier JSON contenant une suite d'enregistrements est obligatoirement associé à une liste chaînée ou une map. Tu auras compris que associée à une map la recherche est ultra rapide.

Oui ça je sais mais avec une structure du genre On prendra par exemple l'id comme clé, mais si on doit trouvé un nom ? Alors il faut faire plusieurs map mémorise l'id. Maintenant si on veut faire une recherche du type like ?

Donc pour moi une base Sqlite est plus approprié et pas plus compliqué à mettre en place.

Si on sauvegarde dans un fichier JSON, ça veut dire qu'on a peu de données, qu'on charge tout en RAM et donc que l'indexation ne sert à rien.

(Au siècle dernier, FoxPro 2 (DOS) conseillait de ne faire des fichiers d'index qu'à partir de 100 000 enregistrements... et on fonctionnait sur des PC 286 à 12MHz, c'est dire si on sous évalue les possibilités actuelles des PC et on fait des fichiers d'index pour rien le plus souvent, sauf pour gérer les doublons sur les clés)

Bref, si on charge toutes les données en mémoire, dans une liste structurée, il est facile de parcourir tous les champs (avec ForEach)
Pour une recherche LIKE, il suffit d'utiliser Left(), Right(), Ucase(), Lcase()
(C'est par contre plus compliqué pour faire une recherche par phonème.)
(Programmation propre, enfin j’essaye) Mais cela dit, JSON n'est pas une base de données, c'est une structure qu'on sauvegarde dans un fichier texte.
C'est comme un fichier XML
C'est même moins bien qu'un fichier pref (fichier INI) qui lui est capable de faire des lectures écritures partielles.

Ça n'a rien à faire dans un programme de gestion de stock, de compta, de facturation qui va vite avoir plusieurs milliers d'enregistrements.

>>>>>>>>>>>[TUTO débutants] les modules<<<<<<<<<<<<<<<<

Et donc sinon le Json... On disait quoi à propos d'un forum illisible ?

boby a écrit :>>>>>>>>>>>[TUTO débutants] les modules<<<<<<<<<<<<<<<<
Et donc sinon le Json... On disait quoi à propos d'un forum illisible ?

Un forum est un lieu de conversation, et toute conversation humaine peut dériver.
Même les chatbost qu'on trouvent sur les sites de e-commerce dérivent aussi (mais à cause de la pauvreté de l'« intelligence artificielle »)

Quand ça dérive trop, ou sur demande aimablement formulée auprès d'un modo, celui-ci a une fonction pour scinder le topic en 2 au bon endroit et donner un nouveau titre.
(ici, il faudra couper à partir de la réponse d'Omega page 1 et déplacer la suite ailleurs)

Tu as un petit point d’exclamation rouge en bas à droite (si tu es connecté) pour signaler directement aux modos n'importe quel message.

Regardez ce que j'ai trouvé sur le net:The absolute maximum length is the largest possible length for a JSON type. This limit is 16776192 bytes.
https://info.teradata.com/htmlpubs/DB_T ... 28253.html