Discussion :

[patrice@]

Bonjour à tous,
Le contexte : j'ai construit une application utilisant plusieurs fichiers séquentiels genre ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
  TEnregistrement=Record
    Champ1:String[10];                      
    Champ2:String[20];                   
    Champ3:String[50];                     
    Champ4:String[100];

Très bien jusqu'au moment ou je tombe sur ce tutoriel sur les fichiers https://fbeaulieu.developpez.com/guide/?page=page_13 qui me fait prendre conscience que dans mes fichiers, je n'utilise quasiment jamais la totalité de la place prise par les champs et qu'il y a donc moyen de réduire la taille des champs à la longueur réelle de l'information contenue (partie sur les fichiers binaires de cet article)

Super, et je me dis que je vais pouvoir en profiter pour ajouter en tête de fichier un certain nombre d'information (par exemple la date et heure du dernier accès au fichier), information qui n'a rien à faire dans les champs du fichier ...

Et puis je tombe sur les Streams, entre autre https://delphi.developpez.com/faq/?p...classe-TStream

Et du coup ... je ne sais pas quoi choisir comme méthode! J'ai bien cherché des comparatifs, mais sans grand succès.

Mon objectif est :
- avoir une structure de fichier la plus compacte possible (pas de blanc pour remplir des zones non utilisée : par exemple 'BONJOUR' dans le champs4 (String[100]) donne 93 octets vides!
- Pouvoir écrire/lire des informations avant les enregistrements
- je ne gère que des type strings (en réalité shortstring), rien d'autre.
- Rapidité d'accès à un enregistrement

Vous pouvez m'aider à débroussailler le foutoir ?

[tourlourou]

Bonjour,
Pour ma part, hors l'utilisation d'une BDD locale type SQLite, je pense que je me dirigerais vers un TStringList avec ses méthodes SaveToFile et LoadFromFile. Je réserverais la 1ère ligne, d'indice 0 pour mes infos, encodées en base64. Les n champs du ième TRecord seraient donc les lignes d'indices i*n+1 à i*n+n.

[patrice@]

Une précision sur l'idée de la taille d'un fichier :
10 Mo au minimum
20 000 enregistrements au minimum contenant 51 champs

[SergioMaster]

Bonjour,

je pensais avoir répondu mais les aléas du travail ont dû faire que je ne l'ai pas fait. Maintenant que le volume des données est défini c'est encore plus facile.
Le fichier séquentiel avec 20000 enregistrements et une contrainte de rapidité d'accès ça me paraît compromis.
Sinon ce qui est décrit n'est ni plus ni moins qu'un fichier CSV de longueur variable

ajouter en tête de fichier un certain nombre d'information (par exemple la date et heure du dernier accès au fichier),

ça c'est inutile il s'agit déjà de propriétés de fichier que l'on peut obtenir.
Reste la question de traitement des données s'il s'agit uniquement de données qui ne seront pas traitées (i.e sélection selon la valeur d'une colonne) aucun problème. Si par contre il s'agit de pouvoir faire des recherches de données le même problème que la rapidité d'accès va se poser.

[patrice@]

Arfff, ce n'était qu'un exemple l'info de la dernière ouverture ... en fait il y a diverses infos concernant ce fichier que j'aimerai mettre en tête du fichier.
Le fichier est en fait un fichier d'écritures comptables ... donc, oui, il y a des recherches et des modifications, et des suppressions.
Dans ma version de base (fichier séquentiel) je me sers d'une Stringgrid qui accueille tout le fichier lors de l'ouverture du dossier et je manipule la StringGrid (du coup l'idée du fichier type CSV est pertinente)

Mais en lisant des articles sur les Stream, j'ai l'impression que je peux faire plus rapide et plus efficace en travaillant directement à partir du fichier sans passer par une StringGrid.
Pour le moment, je balance du coté des Streams, mais mes tests merdent complètement : je suis parti de l'exemple (dans la conclusion de l'article on peut télécharger le projet) https://flash-koti.developpez.com/ar...4-tfilestream/. Mais si on édite son fichier test.zio avec un editeur hexa et qu'on regarde la partie String, on se rend compte que chaque caractères prend 2 octets et non 1, du coup length(chaine) ne réserve pas suffisamment de place et la chaine est tronquée à sa moitié!

Plouf plouf ... je patauge

[alheuredudejeuner]

Bonjour

sinon avec ado, on peut lire les fichier texte en requêtant comme sur une base de données en lecture.

Pour l'écriture je ne l'ai pas fait, ce n'était peut-être pas possible en écriture.

Ce qui serait cool, c'est de l'avoir avec Firedac.

Cordialement

[Paul TOTH]

file ou TFileStream, c'est juste une question d'API car au final ça revient au même, ce sont les mêmes fonctions d'accès aux fichiers qui seront utilisées.

par contre entre un record à taille fixe et un enregistrement compacté c'est pas la même chose. Si tu veux accéder au nième enregistrement, dans le premier cas c'est "SizeOf(Record) * n" et c'est bon, dans le second cas tu as contraint d'avoir une table d'index qui te donne la position dans le fichier de chaque enregistrement. Par ailleurs, ajout/suppression en record statique c'est facile, tu peux noter un record supprimé et le réutilisé pour stocker un autre...avec des données de taille variable ce n'est pas toujours possible.

pour la rapidité d'accès il existe aussi le File Mapping qui permet de faire correspondre un espace disque avec un espace mémoire.

après, si les données au total tiennent en mémoire, tu peux te contenter d'une lecture écriture de flux, y compris avec compression si tu veux un truc tout petit mais un peu moins rapide.

[Roland Chastain]

Bonjour ! Vous pourriez être intéressé par cet exemple.

[patrice@]

Pour le soucis des fichiers ne contenant que la moitié des infos car les caractères sont codés sur 2 octets et non sur 1 la réponse est ici : https://www.developpez.net/forums/d1...eres-bizarres/

Roland, c'est ton article qui a été le déclencheur de tout

ADO ... il me semblait qu'on avait des composants ... qui n'ont plus l'air d'être là (Delphi 10.2)

ok compris pour le reste : des choix et des compromis (pour les 10 ans à venir!)

[SergioMaster]

Dans ma version de base (fichier séquentiel) je me sers d'une Stringgrid qui accueille tout le fichier lors de l'ouverture du dossier et je manipule la StringGrid (du coup l'idée du fichier type CSV est pertinente)

pertinente pour du stockage de base ou de l'échange de données, digne des années cartes perforées. Un simple indicateur en debut de ligne permettant de savoir de quel type d'information il s'agit
i.e 0 - informations générales
1- écritures
2- information optionnelle pour l'écriture

Mais si on édite son fichier test.zio avec un editeur hexa et qu'on regarde la partie String, on se rend compte que chaque caractères prend 2 octets et non 1,

c'est l'avènement de l'Unicode depuis D2009 String un une chaine Unicode (soit, en gros : 2 octets pour un char) pour "retrouver" quelque chose des années ante-unicode (un char=un Octet) il faut
utilisé des AnsiString

À mon avis vous voulez réinventer une roue qui a un nom : ISAM (roue utilisée par nombre de SGBD). Il serait certainement temps de sauter le pas ?

Quand j'ai lu pour la première fois votre demande, ma première réponse commençait par : je suis étonné de voir quelqu'un préoccupé par "l'économie d'octets" à notre époque c'est devenu rare ! Cette chasse aux octets, typique des années 70-80 (que ce soit pour le stockage de données ou pour la mémoire utilisée) n'est plus vraiment d'actualité même celle de l'utilisation de la CPU semble devenue obsolète laissant la place à la meilleure utilisation des multi cœurs et la fuite mémoire.

[wheel]

regarde sur cette petite base de donnée ici