PureBasic

(pour ne pas polluer le topic [TUTO débutants] les modules)

4. Quelle est le type de bases de données préféré pour un logiciel de gestion commerciale?
Fichier.Data? Fichier.Json? .Sqlite?

- Un seul utilisateur ou des écritures rapides: SQlite
- Plusieurs utilisateurs: PostgreSQL
- MySQL/MariaDB, facile, mais ne gère pas les transactions sur les commandes DDL (ie: DROP, ALTER), donc perso, j'évite. De plus (pour l'instant) avec PB il faut passer par un pilote ODBC

Dans tous les cas, toutes les tables dans une seule base pour pouvoir utiliser les outils de cohérences de la base et pour les raisons suivantes:
Cela permet de manipuler toute la base hors programme si besoin (exemple avec un outil graphique) ce qui est fort complexe dans le cas de plusieurs tables.
Sauvegarde facile par fichier ou par dump

SQLite à l'avantage de n'avoir qu'un seul fichier de données quelques soit le nombre de tables, il se comporte donc comme le tablespace d'un gros SGBDR. Il a son propre système de fichier dans le fichier unique et donc vis-à-vis de l'OS n'utilise qu'un seul handle de fichier.

Faire des bases mono-tables n'est pas une bonne idée, car on multiplie les handles de fichiers qui doivent être gérés par le système en plus du programme lui-même. Il est très difficile et lent de gérer correctement plusieurs bases ensembles (ouverture/fermetures/accès concomitants) et si ensuite on passe à plusieurs utilisateurs en réseau, ça devient la cata. Il faut penser qu'un programme n'est jamais terminé, donc simplifier et standardiser au maximum.

Pour l'histoire: Il existe des bases de données spécialisées mono-table. Elles fonctionnent comme une map, mais permettent les transactions et le verrouillage d'enregistrement.
Ca se faisait et se fait encore dans certains cas (ex: annuaires LDAP) avec des systèmes de base de donnée sous forme de lib interne à l'environnement de dev. Ex: Berkeley DB, mais PB ne gère pas
https://fr.wikipedia.org/wiki/Berkeley_DB

Il y à différentes manières de travailler avec une base Sql, on lit les données et les affiche directement vers l’interface utilisateur (à une liste icon,une liste view ou autre) sans les stocker vraiment en mémoire avec un select, on n'a donc pas besoin de structure pour les dites données.

En édition on modifie ou on ajoute la donnée directement dans la base avec un Update. La gestion de base donnée sera en sauvegarde automatique.

La deuxième méthode consiste à stocké les données dans un model de données et puis de les afficher toutes ou partiellement vers l’interface utilisateur. Cela peut être pratique pour effectuer certaine tache.

La première méthode utilise monis de ram et est plus rapide, puisqu'il n'y a pas d'opération intermédiaire pour stocker les données.

La deuxième méthode est plus gourmande en mémoire puisque les données y sont stockées et moins rapide puisque cela demande des opérations intermédiaires .

Le choix dépendra donc du type de projet.

Oui,
Ajoutons aussi comme élément de choix, le fait qu'il est possible de trier une structure (sur n'importe quel champ) alors que ce n'est pas possible de le faire dans le gadget (le gadget grille (ListIconGadget) n'ayant pas de fonction de tri, ni par ligne ni par colonne.)
Si on travaille directement sur le gadget grille, il faut alors refaire un chargement SQL avec un ORDER BY
(ou recharger les éléments du gadget dans une structure, la trier et recharger le gadget)

Les listes ou tableaux de structures peuvent être triées:
SortStructuredList(Liste(), Options, OffsetOf(Structure\Champs), TypeOf(Structure\Champs) [, Debut, Fin])
SortStructuredArray(Tableau(), Options, OffsetOf(Structure\Champs), TypeOf(Structure\Champs) [, Debut, Fin])

Bonsoir

Il y à différentes manières de travailler avec une base Sql, on lit les données et les affiche directement vers l’interface utilisateur (à une liste icon,une liste view ou autre) sans les stocker vraiment en mémoire avec un select, on n'a donc pas besoin de structure pour les dites données.

C'est exactement ce que je faisais sur l'ensemble de mes programmes y compris celui que j'ai posté récemment. Mais, la plupart d'entre vous (G-Rom, toi et d'autres...) n'étaient pas d'accord... (Mise à part l'organisation et l'aération)...

La deuxième méthode consiste à stocké les données dans un model de données et puis de les afficher toutes ou partiellement vers l’interface utilisateur. Cela peut être pratique pour effectuer certaine tache.

C'est ce que j'allais faire maintenant sur le nouveau programme que j'ai déjà entamé d'ailleurs (conformément aux conseils de l'équipe)... mais à présent, je ne sais plus quoi faire... continuer ou revenir sur la première méthode que j'utilisais depuis des années... (qu'en penses tu?)

La deuxième méthode consiste à stocké les données dans un model de données

J'aimerais comprendre une chose: est ce qu'il faut stocker un seul enregistrement à lafois et faire les traitements? (comme si on utilisait des variables mémoires?) ou alors l'ensemble des enregistrements (en utilisant addElement()?)

Les listes ou tableaux de structures peuvent être triées

Oui, justement j'utilisais les structures uniquement pour ça (affichage trié par le champs défini par l'utilisateur) (voir exemples sur mon code posté récemment). Maintenant une question se pose: Que faut il choisir? Sqlite (en lecture et écriture directement) ou un autre type de bases de données (comme .json par exemple?) les structures peuvent être utilisée dans les deux cas mais dans des buts différents...
Merci

A l'école et particulièrement en java on te dirais qu'il faut faire 3 couches ,une pour le model, une pour la liaison Db et une autre pour l'ui.

J'ai réaliser plusieurs softs de gestions sans model de données et cela fonctionne parfaitement, évidement cela ne peut fonctionner qu'avec des base de données type sql ou l'on peut exécuter des requête de sélection.

Pour contourner la chose je me suis fait un module avec qui gère une table view personnalisée qui directement liée à une table personnalisée. L'utilisateur tri la table poser des filtres ou même faire une recherche (ce type de table n'existe pas toute faite même en JavaFx) l'avantage la base n'est lue que des enregistrements visible et le scrollbar faire avancé la table. Même avec une table de 10000 records c'es super rapide. Seul hic je suis limiter à 12.000 record que c'est la limite d'un scrollbar.

Maintenant si t'on soft fonctionne, ne vaut'il pas mieux le laissé ainsi ou seulement le réorganiser

Exemple de ma table réalisée avec un canvas.

A chacun sa méthode, moi pendant longtemps je travaillais avec des bases SQLite, mais depuis que j'ai essayé json, je ne suis jamais retourné au système SQLite car je trouve json beaucoup plus simple à mettre en œuvre, mais ça n'engage que moi.

Bonjour à tous
@Micoute

A chacun sa méthode, moi pendant longtemps je travaillais avec des bases SQLite, mais depuis que j'ai essayé json, je ne suis jamais retourné au système SQLite car je trouve json beaucoup plus simple à mettre en œuvre, mais ça n'engage que moi.

Dans ce cas, Json a surement un avantage par rapport à sqlite? puis-je savoir lequel ? En matière de capacité de données, y a t il une limite ? (il semble que Json ne peut pas gérer plus de quelques centaines d'enregistrements?)
@Microdevweb

Maintenant si t'on soft fonctionne, ne vaut'il pas mieux le laissé ainsi ou seulement le réorganiser

Oui, c'est exactement ce que j'ai l'intention de faire, du moment que je suis en train de refaire le soft (de A à Z), d'abord pour le réorganiser et le rendre plus aéré, j'ai pensé profiter de l'occasion pour améliorer le soft au maximum, (s'il y a mieux que sqlite, pourquoi pas ne pas changer maintenant avant qu'il ne soit trop tard?)
J'ai déjà commencé le new soft (je suis au niveau des déclarations....)
Merci à vous deux pour vos conseils

Regardez ce que j'ai toruvé 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

(il semble que Json ne peut pas gérer plus de quelques centaines d'enregistrements?)

Le Json n'a pas particulièrement de limite, plus il est chargé plus il est lent... mais le Json n'est pas un système de base de donnée...

SQL = stockage de donnée de tout type (voir blob)
SQL = fonction de recherche, trie en tous genre, relation entre différentes table j'en passe et des meilleurs
SQL EST une base de donnée fait pour encaisser des charge importante.

Toi vouloir faire base de donner, toi utiliser SQL. Ça être compréhensible ?

Toi vouloir faire base de donner, toi utiliser SQL. Ça être compréhensible ?

Merci boby (le message précédent c'était juste pour infos..)
Ok pour sqLite ! Goooooo.... !

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.

Micoute a écrit :ça n'engage que moi.

On ne peut pas meilleur verrouillage.

djes a écrit :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.

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é

microdevweb a écrit :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