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

Vous débutez et vous avez besoin d'aide ? N'hésitez pas à poser vos questions
Marc56
Messages : 2146
Inscription : sam. 08/févr./2014 15:19

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

Message par Marc56 »

(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

:wink:
Avatar de l’utilisateur
microdevweb
Messages : 1798
Inscription : mer. 29/juin/2011 14:11
Localisation : Belgique

Re: Choix d'un système de base de donnée en fonction de l'us

Message par microdevweb »

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.
Windows 10 64 bits PB: 5.70 ; 5.72 LST
Work at Centre Spatial de Liège
Marc56
Messages : 2146
Inscription : sam. 08/févr./2014 15:19

Re: Choix d'un système de base de donnée en fonction de l'us

Message par Marc56 »

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])

:wink:
Avatar de l’utilisateur
omega
Messages : 617
Inscription : sam. 26/nov./2011 13:04
Localisation : Alger

Re: Choix d'un système de base de donnée en fonction de l'us

Message par omega »

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
Win7 (x64) 64 bits Pb 5.72
Avatar de l’utilisateur
microdevweb
Messages : 1798
Inscription : mer. 29/juin/2011 14:11
Localisation : Belgique

Re: Choix d'un système de base de donnée en fonction de l'us

Message par microdevweb »

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.
Image
Windows 10 64 bits PB: 5.70 ; 5.72 LST
Work at Centre Spatial de Liège
Avatar de l’utilisateur
Micoute
Messages : 2522
Inscription : dim. 02/oct./2011 16:17
Localisation : 35520 La Mézière

Re: Choix d'un système de base de donnée en fonction de l'us

Message par 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.
Microsoft Windows 10 Famille 64 bits : Carte mère : ASRock 970 Extreme3 R2.0 : Carte Graphique NVIDIA GeForce RTX 3080 : Processeur AMD FX 6300 6 cœurs 12 threads 3,50 GHz PB 5.73 PB 6.00 LTS (x64)
Un homme doit être poli, mais il doit aussi être libre !
Avatar de l’utilisateur
omega
Messages : 617
Inscription : sam. 26/nov./2011 13:04
Localisation : Alger

Re: Choix d'un système de base de donnée en fonction de l'us

Message par omega »

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
Win7 (x64) 64 bits Pb 5.72
Avatar de l’utilisateur
omega
Messages : 617
Inscription : sam. 26/nov./2011 13:04
Localisation : Alger

Re: Choix d'un système de base de donnée en fonction de l'us

Message par omega »

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
Win7 (x64) 64 bits Pb 5.72
boby
Messages : 261
Inscription : jeu. 07/juin/2007 22:54

Re: Choix d'un système de base de donnée en fonction de l'us

Message par boby »

(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 ?
Avatar de l’utilisateur
omega
Messages : 617
Inscription : sam. 26/nov./2011 13:04
Localisation : Alger

Re: Choix d'un système de base de donnée en fonction de l'us

Message par omega »

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.... !
Win7 (x64) 64 bits Pb 5.72
Avatar de l’utilisateur
djes
Messages : 4252
Inscription : ven. 11/févr./2005 17:34
Localisation : Arras, France

Re: Choix d'un système de base de donnée en fonction de l'us

Message par 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
Messages : 4190
Inscription : ven. 29/juin/2007 17:50
Localisation : Encore ?
Contact :

Re: Choix d'un système de base de donnée en fonction de l'us

Message par Ollivier »

Micoute a écrit :ça n'engage que moi.
On ne peut pas meilleur verrouillage.
G-Rom
Messages : 3626
Inscription : dim. 10/janv./2010 5:29

Re: Choix d'un système de base de donnée en fonction de l'us

Message par G-Rom »

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.
Avatar de l’utilisateur
microdevweb
Messages : 1798
Inscription : mer. 29/juin/2011 14:11
Localisation : Belgique

Re: Choix d'un système de base de donnée en fonction de l'us

Message par 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é
Windows 10 64 bits PB: 5.70 ; 5.72 LST
Work at Centre Spatial de Liège
Marc56
Messages : 2146
Inscription : sam. 08/févr./2014 15:19

Re: Choix d'un système de base de donnée en fonction de l'us

Message par Marc56 »

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

:wink:
Verrouillé