DOCUMENTATION RESCUE FOR 4D Data - 4ème Dimension


| Accueil WEB JCS| Sommaire| Avertissement | Historique des Versions | Installation |
Quelques conseils pour mieux utiliser Rescue for 4D Data
|
| Menus | Préferences | Navigator | Doctor | Editor | Viewer |
| 4th Dimension™ | Structure du Data 4ème Dimension™ |


4ème Dimension

4ème Dimension est un Système de Gestion de Base de Données Relationnelles (SGBDR) édité par la société ACI SA.

4ème Dimension™ crée 2 fichiers distincts :

La maintenance de la base s'en trouve largement simplifiée puisque le fichier contenant la programmation et le fichier contenant les données saisies sont totalement distincts.

Malheureusement et trop souvent, il arrive qu'un problème (Bug, plantage machine, coupure de courant,...) puisse rendre inutilisable soit :


Structure du Data 4D
 

 

Le graphe ci dessus montre, en résumé, la structure d'un data 4D.

DSH
Data Segment Header. Entête du fichier de données. Il contient les informations principales de la base ainsi que les liens vers les autres objets.
FIT
File Information Table. Contient les informations sur les tables et leur organisation.
FI
Contient le détail de chaque table (nombre de fiches, position, delete table, etc...).
PRA
Primary Record Address. Adresse primaire des enregistrements. Pointe sur les SRA. Une PRA peut pointer sur 4096 SRA.
SRA
Secundary Record Address. Adresse secondaire des enregistrements. Pointe sur les enregistrements. Une SRA peut pointer vers 1024 enregistrements en v5 ou 512 en v6.
IHT
Index Headers Table. Contient les informations sur les index et leur organisation.
II
Index Informations. Contient les détails de chaque Index (nombre d'index, position, etc...).
PIAT
Primary Index Address Table. Adresse primaire des index. Pointe sur les SIAT. Une PIAT peut pointer sur 4096 SIAT.
SIAT
Secondary Index Address Table. Adresse secondaire des index. Pointe sur les pages d'index. Une SIAT peut pointer vers 4096 Page d'index.
IP
Index Page. Les index sont contenus et classés dans ces pages.
 
 
Structure d'un Enregistrement
 
 
 
Header Record
Cette zone contient des informations sur la fiche (Checksum, numéro de fiche, taille, etc).
Field Information
Contient la position et le type de chaque champ sauf les champs de taille variable 'Texte, Picture, Blob, et Sous-fiche'.
Data Of Fixed Fields
On trouve ici les données des champs de taille fixe (alpha, num, entier, etc)...
Data Of SubFields
Ici, on peut trouver sous forme de "sous-enregistrement" toutes les fiches d'une sous-structure, voire même toutes les fiches de la sous- structure de la sous-structure de la...
Data Of Variable Fields
Les données des champs à taille variable comme les 'Textes, Blobs, Pictures'. Cependant, il n'y a pas de pointeur sur ces champs, ce qui force 4D à les parcourir tous avant d'arriver à celui de votre choix.
 
 
Commentaire sur les Sous-structures :
 
 
Vu du Développeur :
 
  • 4D ne sait pas construire des états semi-automatiques sur les sous-structures.
  • Il ne sait pas non plus construire des graphes sur les sous-structures sans passer par un tableau.
  • Les Import/Export de sous-structures passent forcément par de la programmation.
  • Une fois créées, les sous-structures deviennent indestructibles.
  • Il est impossible de faire des sous-sélections de sous-structures.
  • Il est impossible d'afficher dans une liste de sous-structures plus de 32000 lignes : c'est une limite du List Manager de 4D.

    Vu de 4D :

  • Les sous-structures sont des fiches dans les fiches. Donc, si une fiche est endommagée, vous perdez toutes les sous-fiches.
  • Comme il n'y a pas de pointeur de sous-fiches, 4D est obligé de parser l'ensemble des sous-fiches avant d'arriver à celle que vous désirez consulter.
  • Si une seule de vos sous-fiches est endommagée, c'est la fiche entière qui ne pourra pas être lue.
  • Les champs de taille variable se trouvent après les sous-fiches ; pour y accéder, 4D devra lire la totalité des sous-fiches.
  • 4D ne sait pas lire une partie de fiche quand vous demandez des données ou quand vous faites une recherche ou un tri.
    Ce défaut oblige 4D à charger en mémoire la fiche entière, et donc, ses sous-fiches. Cela demande du temps et bien sûr, de la place mémoire.
    Si la place n'est pas disponible dans le cache à ce moment là, 4D le Flushe. Nous vous laissons imaginer la perte de temps pour accéder à un simple champ...
  • La modification d'un seul champ, dans ce genre de fiche, provoque d'abord la réorganisation mémoire, puis disque, de TOUTE la fiche.
  • Lorsque dans une liste 4D, on affiche un champ de taille variable, type Texte par exemple, l'affichage est CONSIDERABLEMENT ralenti par la présence de sous- fiches.
  • Si on multiplie le nombre de PIAT(512) * SIAT(512) * IP(64) = 16 777 216 d'index sur un champ. Soit le nombre maximum de fiches par table.
    Or, une fiche peut contenir de 0 à x sous-fiches. Imaginons une base de 1,2 Millions d'enregistrements contenant chacuns 20 sous-fiches : cela donne 24 millions de sous- fiches. Si un champ des sous-fiches est indexé, 4D NE POURRA PAS CREER L'INDEX.

    Ces remarques ne démontrent-elles pas qu'ACI :

    • Ne pensait pas aux sous-fiches comme une solution vraiment viable ????
    • N'a pas pensé qu'il y aurait, un jour, des bases avec des tailles aussi importantes ;-))
    • N'a pas fait les sous-fichiers pour durer dans le temps ;-)))))))


Avancée | Aide
| Accueil WEB JCS| Sommaire| Avertissement | Historique des Versions | Installation |
Quelques conseils pour mieux utiliser Rescue for 4D Data
|
| Menus | Préferences | Navigator | Doctor | Editor | Viewer |
| 4th Dimension™ | Structure du Data 4ème Dimension™ |