Bonjour,

- Voici le schema du dataflow :

fichier excel -> traitement1 -> stockage tampon -> traitement2 -> exportation 

- Voici le contexte :

Le traitement2 étant plus lourd et une masse d'arrivage de fichier excel étant possible,  le traitement2 doit se faire de façon asynchrone vis à vis du traitement1

- La problematique :

L'exportation finale après traitement2 doit se faire par bloc d'excel reçu par le traitement1.

- La question :

Laquelle de ces methodes est la plus apte :

• PostgresSQL ou MongoDB : une table correspondra à un bloc excel => on m'a dit que faire correspondre une insertion de bloc à une table n'était pas très orthodoxe pour PostgresSql, qu'en pensez vous? et pour le cas de MongoDB?
• Fichier : un fichier correspondra à un bloc excel 

Cordialement,

Bonjour,

Un simple attribut reprenant la référence au fichier Excel dans la table est suffisante non ?

Avec une base de données relationnelle (PostGreSQL) :

• Une seule table "tampon" avec les colonnes nécessaires à l'import Excel + une colonne avec la référence au fichier + une colonne booléenne "export" (valant 1 si la ligne a été exportée sinon 0)
• On pourrait envisager une deuxième table qui listerait les fichiers importés, avec juste un ID, le nom du fichier et son chemin absolu. Dans la table tampon tu pourrais alors mettre une clé étrangère vers l'ID de cette deuxième table pour une référence plus forte

Avec une base de données NoSQL (MongoDB) :

• Une collection "tampon" avec les attributs nécessaires à l'import Excel + un attribut avec la référence au fichier + un attribut booléen "export" (valant 1 si la ligne a été exportée sinon 0)

enzouye a écrit:

Bonjour,

Un simple attribut reprenant la référence au fichier Excel dans la table est suffisante non ?

Merci d'avoir repondu :D 

Ce que je n'avais pas precisé est que je voudrais eviter les clés secondaires etant donné qu'on parle de million de lignes et qu'une condition WHERE entrainerait une latence considerable (à mon avis, le debat est ouvert) par rapport aux solutions que j'ai proposées. 

-
Edité par JairygonZ 23 février 2022 à 11:37:00

PostGreSQL est tout à fait capable de stocker des millions d'enregistrements ... et les temps de réponse seront acceptables du moment que les données sont indexées correctement ... et ici rien de compliqué ou complexe ...

Je suppose par ailleurs que le million de lignes ne va pas être atteint en dix minutes ni même en un mois ... Tu auras le temps de faire du nettoyage périodique. Je dis cela car d'imagine qu'une fois les données exportées, rien ne sert de les garder en base pendant des années, un archivage à intervalle régulier peut peut-être être envisagé ...

Attention, je ne prône pas SQL au détriment de NoSQL, je dis que dans le contexte décrit je ne vois pas de frein à utiliser SQL, y compris avec une contrainte d'intégrité référentielle sur une table avec des dizaines de millier d'enregistrements.