Discussion :

[Invité]

Bonjour,

Je n'ai pas trouvé de forum adapté à ma demande, celle-ci est plus général que le thème de ce forum. Elle ne concerne aucun langage de programmation particulier.
J'espère recevoir des réponses ici, sinon pouvez-vous m'aiguiller vers le forum adapté ? merci

Je dispose d'une très grande carte, cette carte est découpée en plusieurs morceaux de taille identique.
Pour chaque morceau, je peux avoir des données de taille variable a persister. Je ne souhaite les récupérer et les persister que morceau par morceau.
Ma première approche, c'est de créer un fichier par morceau. Comme ça, lorsque je sauvegarde les données d'un morceau, j'ai juste a écrire dans ce nouveau fichier, quand je les lis il me suffit juste de lire le fichier séquentiellement et quand je les supprime j'ai juste a supprimer le fichier.
A contrario si je ne fais qu'un seul fichier, dès que je modifie la taille de mes données, il va falloir réécrire l'ensemble du fichier pour faire en sorte qu'il n'y ait pas de trous ou que les données à insérées ne débordent pas sur les données suivantes.

Cependant je pense que créer une multitude de fichiers aura d'autre impacts sur les performances, sinon pourquoi par exemple les données d'une BDD SQlite sont elles toutes dans un seul fichier ?

Pour info je développe en Java et mon programme est destiné a tourné sur tout les système de fichier contemporain courant chez des particuliers.

[el_slapper]

C'est une question hautement philosophique, pour laquelle chacun a sa réponse.

Moi, perso, j'aurais tendance à garder des fichiers cohérents, donc, dans ton cas, multiple. Si et seulement si les performances deviennent atroces, et si et seulement si le fichier unique permet de s'en sortir, alors j'irais au fichier unique. C'est moins beau, mais c'est TOI, au final, qui fixe tes propres exigences. Pas moi.

[DonQuiche]

D'abord as-tu vraiment un problème de performances ? Si ce n'est pas le cas privilégie la simplicité du code et l'intégrité des données.

En termes de performances un fichier unique peut être plus rapide en lecture : arrangement personnalisé des données dans le fichier, pas d'accès intempestif aux données du système de fichiers, moins de temps passé dans le noyau, etc. Et pour les mêmes raisons il peut être plus efficace en écriture pourvu que tu ne réécrives pas tout le fichier mais seulement les parties modifiées (stream.seek ou un truc de ce genre). Si les morceaux n'ont pas une taille constante il te faudra un index au sein du fichier. Dans tous les cas la solution à un seul fichier est plus complexe mais offre davantage de possibilités d'optimisation (gestion perso du cache & co).

Concernant la préservation de l'intégrité des données, c'est difficile à accomplir avec un seul fichier et ça réclame d'utiliser des API transactionnelles spécifiques à chaque OS. C'est beaucoup plus simple à accomplir avec des fichiers multiples et un hash en fin de fichier (voire un CRC, plus rapide mais parfois suffisant). Le plus radical dans ce cas serait de stocker des blobs dans une DB afin de s'appuyer sur le SGBD pour prendre en compte ces problèmes, mais c'est peut-être moins efficace en termes de performances (ou pas - ça pourrait être plus rapide qu'une solution naïve).

Bref : à moins d'avoir d'avoir des besoins très particuliers, j'opterais pour des fichiers multiples ou un SGBD.

[Invité]

Merci pour vos réponses

D'abord as-tu vraiment un problème de performances ? Si ce n'est pas le cas privilégie la simplicité du code et l'intégrité des données.

Oui je ne prend pas que la performance en compte S'il n'y a pas de grande différence, je prendrais la méthode la plus simple.
En réalité il s'agit d'une application serveur multi-utilisateur (l'accès aux données ne se fait que par un seul thread donc pas de soucis la dessus) et j'aimerai qu'elle soit scalable un minimum. Donc je me demandais si trop de fichiers pourrais me poser des problèmes bloquants au bout d'un moment parce que je peux avoir beaucoup de morceaux.

C'est beaucoup plus simple à accomplir avec des fichiers multiples et un hash en fin de fichier

Je pensais simplement utiliser les coordonnées du morceau comme nom de fichier pour pouvoir ensuite le récupérer. Ça pose peut-être d'autre problèmes ? Dans mon cas, j'ai la garantie que les coordonnées d'un morceau sont unique et peuvent donc me servir d'identifiant.

Bref : à moins d'avoir d'avoir des besoins très particuliers, j'opterais pour des fichiers multiples ou un SGBD.

Oui c'est la solution de secours que j'ai prévu si les fichiers multiples ne sont pas adaptés Passer par un blob sur SQLite
Je n'ai pas assez de temps a accorder pour la construction d'un lourd système de gestion de données, et je doute en avoir les compétences

[Invité]

J'ai finalement choisis la solution SGBD.
J'ai choisis MapDB qui me semble plus adapté à mon besoin que SQLite.
(Cf. http://www.developpez.net/forums/d15.../choix-d-sgbd/)

L'avantage c'est que je n'ai pas à m'occuper de la partie DB et ce n'est pas plus mal, ça me permettra d'avancer sur la partie métier de mon application.
J'ai regardé quelques benchmark, je ne sais pas ce que ça vaut, ça fait très vendeur En tout cas ça à l'air de convenir à l'utilisation que je souhaite en faire

Je passe le sujet en résolu