Bonjour, je réalise une application est un problème d'optimisation se pose.

J'ai des données statiques que je dois stocker et je ne sais pas quelle est la meilleure solution.

Par exemple, je stocke la liste de tous les pays.

Vaut-il mieux faire une BDD avec par exemple:

idPays | codePays | nomPays

ou les stocker dans un fichier JSON (ou autre format plus optimisé ?):

{
  "AF": "Afghanistan",
  "ZA": "Afrique du Sud",
  "AL": "Albanie",
  "DZ": "Algérie",
  "DE": "Allemagne",
  "AD": "Andorre",
  "AO": "Angola",
  "AI": "Anguilla",
  "AQ": "Antarctique",
  "AG": "Antigua-et-Barbuda",
  "AN": "Antilles néerlandaises",
  "SA": "Arabie saoudite",
  ...
}

Ces données seront utilisées pour le pays de résidence des utilisateurs et d'entreprises (deux tables séparées)

Et en deuxième exemple, les utilisateurs pourront saisir des transactions (Dépôt, retrait, intérêts perçus, ...).

Donc, j'ai le choix entre BDD:

idTypeTransaction | nomTypeTransaction | estPositive

ou dans un fichier:

{
    "1": {
             "nomTypeTransaction": "Dépôt",
             "estPositive": 1
         },
    "2": {
             "nomTypeTransaction": "Retrait",
             "estPositive": 0
         },
    "3": {
             "nomTypeTransaction": "Intérêts",
             "estPositive": 1
         },
    "4": {
             "nomTypeTransaction": "Loyer",
             "estPositive": 0
         },
    ...

}

Les types de transactions ne seront pas tous disponibles pour tous les types de compte.

Et je voudrais stocker, pour ces deux exemples, également des traductions dans d'autres langues.

Merci d'avance pour vos suggestions et si vous avez des articles qui en parlent, je ne suis pas contre

Après quelques tests de rapidité en interne, il semble que le fichier JSON l'emporte sur la BDD (MySQL). Mais qu'en est-il de la pertinence, la persistance et la cohérence des données ?

-
Edité par tonin2310 24 juillet 2020 à 21:02:27

Bonjour,

Je pense que tu viens de répondre à ta propre interrogation.

Tu compares deux choses totalement différentes au final, d'un côté JSON, un langage de balisage, et de l'autre MySQL, un SGBDR.

C'est sur qu'accèder et parcourir un fichier JSON avec JavaScript c'est simple. Mais ça ne remplace pas des années de développement et d'expérience derrière un système «complet» de gestion de base de données.

En utilisant que JSON, ce sera à toi de produire le code censé s'assurer de: «la pertinence, la persistance et la cohérence des données». JSON n'a pas de notion de clé primaire, clé étrangère par exemple. Quand sera-t-il des accès concurrents à la même ressource ? De la gestion des droits de lecture, d'écriture ? De la sécurité ?

Il n'existe pas que MySQL comme système de gestion, ou à base de SQL d'ailleurs, tu peux utiliser d'autres solutions peut-être à base de noSQL par exemple (dont certaines reprennent le format JSON pour stocker certaines données je crois).

À mon avis, utiliser un système de gestion qui a fait ses preuves est mieux que de tout refaire.

Merci pour ton commentaire 😀

C'est bien ce que je me disais au niveau de la maintenance. Ça peut devenir rapidement compliqué....

À la base, je voulais utiliser PostgreSQL qui me paraît plus intéressant que MySQL pour ce que je souhaite faire. Mais il faut que je me regarde quelques tuto d'abord.

Pour le noSQL, est-ce que les SGBD gèrent bien les relations entre les tables sachant que j'ai une dizaine de tables avec des relations à chaques fois ? Je connais un peu MongoDB, je sais que c'est possible avec les _id mais est-ce que c'est aussi puissant qu'un SGBDR ? 🤔

-
Edité par tonin2310 25 juillet 2020 à 6:55:58

Je n'ai pas assez d'expérience avec les SGBD(R) pour vraiment te répondre sur ce point.

Avec SQL, tu utilises l'algèbre relationnel justement, tu trouveras pas plus puissant pour gérer les contraintes sur tes tables à mon avis.

Avec noSQL, c'est différent, tu ne peux pas gérer les contraintes (ou en tout cas pas directement).

D'accord, merci pour tes réponses. Je vais chercher plus en profondeur

"(...)sachant que j'ai une dizaine de tables avec des relations à chaque fois ?" Et bien.. comme le disais KoaTao tu te donnes toi même les réponses à tes questions Tu as besoin de relations et de contraintes franches entre tes tables : ben go pour du relationnel voyons (par exemple MySQL/MariaDB oui...) !

Tu as besoin de flexibilité (peu ou pas de contraintes, pas de stockage longue durée..) et de traiter un GRAND volume de données ? Le NoSQL est alors intéressant (MongoDB, CouchDB, Firestore...) !

Pour ton besoin, le relationnel à l'air de l'emporter sur tous les points. Je ne sais pas combien de lectures/enregistrements tu auras à faire par seconde, mais je doute que de graves soucis de rapidité pointent le bout de leurs nez. Côté optimisation c'est le design de ta DB et les requêtes qui seront cruciaux.