File di configurazione delle tabelle del database 

Introduzione

La creazione di una tabella viene fatta nel software, tramite uno strumento denominato valfil. Questo strumento è richiamato direttamente dall'ambiente di sviluppo integrato in ADONIX in diversi casi: creazione di una tabella dall'editor delle tabelle, modifica di una tabella dalla stessa funzione, estrazione o integrazione di dati, integrazione di una patch che porta al cambiamento di struttura di una tabella del database.

Di base, una tabella è definita da file fisici che si trovano nella directory FIL del dossier, e da una tabella del database. I file fisici sono i seguenti:

  • un file XXX.srf, che contiene la descrizione della struttura del file (con un formato « ascii » descritto qui di seguito).
  • un file XXX.fde, che contiene la descrizione della struttura del file (in formato compilato utilizzabile direttamente dal motore adonix).

Quando la tabella non è memorizzata nel database, ma è stata scaricata sotto forma di un file trasportabile, si troveranno i suoi dati sotto forma di due o tre file supplementari :

  • un file XXX.dat, che contiene i dati nel formato di un file costituito da record di lunghezza fissa.
  • un file XXX.seq, che contiene il successivo numero di sequenza associato alla tabella. Questa informazione è importante nella misura in cui ogni tabella è associata ad un numero di sequenza che permette di creare numeri univoci (ciò corrisponde alla funzione adonix uniqid([abv]), dove abv è l’abbreviazione della tabella corrispondente).
  • un file XXX.blb, che contiene i dati estesi (blobs e clobs) se ne esistono nella tabella.

Le informazioni contenute in questi diversi file permettono la creazione di una tabella con le seguenti opzioni « a minima » :

  • il dimensionamento della tabella (dimensione prevista, all'occorrenza - per oracle - sotto forma di segmento iniziale e di dimensione di extents) viene definito nel file di estensione .srf (essendo calcolato a partire dal numero previsto di righe nella tabella, definito da variabili e formule di dimensionamento).
  • il dimensionamento degli indici è definito proporzionalmente partendo dalla dimensione della tabella (si moltiplica la dimensione del segmento iniziale per il rapporto tra la lunghezza di chiave e la lunghezza della riga di tabella, poi si impone il next extent della stessa dimensione di quello iniziale).
  • i gruppi di file (sotto SQL server) sono quelli definiti nel file .adxodbc se esiste. Se il file non esiste, si prendono i gruppi di file DOSSIER_DAT e DOSSIER_IDX se esistono, dove DOSSIER è il nome del dossier. In assenza, si prende il gruppo definito di default per il database.
  • i tablespaces di memorizzazione (per oracle) sono quelli definiti nel file .adxora se esiste. Se il file non esiste, si prende il tablespace associato di default allo user DOSSIER per i dati, il tablespace DOSSIER_IDX per gli indici.

Può essere interessante definire delle informazioni complementari utilizzate durante la creazione della tabella e ad ogni suo aggiornamento, per modificare queste regole di dimensionamento o di localizzazione, tenendo conto delle particolarità dei diversi database e ottenere in questo modo migliori prestazioni. Tuttavia questo presuppone di memorizzare questi elementi fuori dal database, affinchè lo strumento valfil possa applicarli ogni volta che sarà fatta una validazione o una rivalidazione della tabella. Ecco perchè è possibile creare un file di estensione cfg nella directory FIL. Questo file permette di registrare un insieme di direttive opzionali che completeranno il comando SQL Create table o Create Index che sarà realizzato da valfil. Così come i file di estensione .srf, è in formato « ascii » (descritto qui sotto).

Il contenuto di questo file di configurazione compare nella parte inferiore del folder di definizione degli indici, nella gestione delle tabelle. Il seguito di questo documento descrive la sintassi di scrittura di questo file di configurazione.

Sintassi di scrittura

Questo file è composto da righe di testo che formano delle sezioni. Ogni sezione inizia con un'etichetta preceduta dal carattere $, seguito da un codice che indica per quale database è fatta questa sezione (sia ORACLE, sia MSSQL), seguito da un carattere di sottolineatura e dal nome della tabella o di un indice.

Vi si trovano in seguito delle opzioni comprese tra i caratteri {" (parentesi graffa seguita da doppi apici) e "} (parentesi graffa preceduta da doppi apici). Queste clausole saranno passate così come sono al database durante la creazione o la modifica della tabella o dell'indice. Se ne esitono diverse, sono passate le une dopo le altre, separate da una fine riga. Il numero di caratteri di una clausola è limitato a 256.

Vi si trova in seguito la parola chiave End, che chiude una sezione.

Dei commenti possono essere inseriti nel file di configurazione, sotto forma di testi liberi prefissati dal carattere # (diesis). Un commento si può trovare solo all'inizio della riga.

Dal momento che esiste una sezione non vuota (con almeno una clausola), tutte le regole di dimensionamento o di memorizzazione di default dell'elemento (tabella o indice) descritte, vengono ignorate a favore delle vecchie clausole.

Una sezione corrispondente ad un elemento esistente, o relativa ad un database che non è il database corrente, viene totalmente e semplicemente ignorata.

Esempi di sintassi oracle

Le clausole di memorizzazione possono essere per esempio:

Tablespace imposto

{" Tablespace ts1 "}

Dimensionamento degli extents della tabella

{" Storage (Initial 100K Next 50K Maxextents 10 Pctincrease 20) "}

Partizionamento di una tabella su più tablespaces secondo il valore di un campo

{" partition by range (DHIDAT_0) (partition p1 values less then ('01-APR-1999') tablespace ts1, "}
{" partition p2 values less then ('01-APR-2001') tablespace ts2, "}
{" partition p3 values less then (maxvalue) tablespace ts4) "}

Esempi di sintassi SQL server

Nelle versioni di runtime consegnate prima della versione 6.4, l'unica istruzione di salvataggio possibile è:

Volume imposto

{" On volume1 "}

A partire dalla versione 6.4, è anche possibile definire che il primo indice (solo lui) sia "clustered", vale a dire che i dati della tabella vengono salvati fisicamente nell'ordine di questa chiave. Ciò può essere utilizzato a scopo di ottimizzazione, aggiungendo ad esempio la sezione seguente (XXXX è il nome dell'indice scelto):

$CLUSTERED
{ "XXXX" }
End

Affinché tale direttiva sia attiva, è importante rivalidare la tabella in modalità forzata dopo aver modificato il file di configurazione.

Attenzione: questa sintassi per definire l'indice "clustered" è temporanea. Difatti, nella prossima versione principale, la definizione degli indici di questo tipo sarà presente in modo più naturale nel dizionario.

Esempio di file

Qui di seguito si trova un esempio di file di configurazione. Si noterà che qui sarà utilizzata solo una parte delle direttive (secondo il database utilizzato, poichè saranno attivate solo quelle che si applicano al database effettivamente utlizzato).

Va notato che la fornitura standard del software non comporta alcun file di configurazione, e che un'aggiornamento rispetta i file di configurazione esistenti. Infatti, i file di configurazione sono considerati come elementi di implementazione e sono necessariamente collegati ad una certa installazione e non ad uno standard qualsiasi.

 

#---  Regola per Oracle: File delle fatture
$ORACLE_SINVOICE
#--- Si impone un tablespace diverso
{" Tablespace DEMO_DAT2 "}
#--- Regole di dimensionamento obbligatorie dal momento che si è imposto qualcosa
{" Storage (Initial 100M  Next 50M Pctincrease 20) "}
End

#---  Regola per Sql Server
$MSSQL_SINVOICE
{" On DEMO_DAT2 "}
End

#--- Primo indice sotto Oracle (Nessuna regola per gli altri indici)
$ORACLE_SIH0
{" Tablespace DEMO_IDX2 "}
{" Storage (Initial 5M Next 2M Pctincrease 30) "}
End

Allegato: i file ascii utilizzati con il motore ADONIX

Il motore ADONIX utilizza dei file ascii di tipo « Unix », vale a dire che il separatore di riga è il Line Feed (carattere di codice 10), e non il Carriage Return, Line Feed (carattere 13, poi 10) come per i file di testo Windows™. E' fondamentale quindi non modificare questi testi con notepad (o almeno non riscriverli con notepad), sennò il motore adonix riuscirà difficilmente a rigestirli. In compenso, l'editor vi è utilizzabile sotto UNIX. Gli editor adonix gestiscono in maniera del tutto corretta questi file.

Bisogna tuttavia notare che il formato utilizzato da questi file è in realtà il formato UTF8 (che è un formato che permette di gestire i caratteri UNICODE - cinese ad esempio - in modo del tutto trasparente. Si tratta quindi in realtà di una codifica da 1 a 4 byte per un unico carattere. Il formato UTF8 corrisponde all'ASCII per tutti i caratteri non accentati, ma se il bit di peso maggiore è 1, il carattere è codificato su più byte. Questo significa che i caratteri accentati francesi non sono correttamente visualizzati con gli editor « classici » (ma gli editor adonix elaborano in modo assolutamente corretto questa transcodifica).

Allegato: le regole di default di dimensionamento delle tabelle

In mancanza di file di configurazione, l'algoritmo di dimensionamento utilizzato per dimensionare le tabelle oracle è il seguente:

  • si determina innanzitutto il numero di righe che è possibile memorizzare nella tabella. Questo numero di righe è calcolato mediante delle formule di dimensionamento, esse stesse calcolate partendo da elementi di dimensionamento. Questo numero di righe è confrontato con il numero di righe fornite nel campo Numero di schede posto nel primo folder del dizionario delle tabelle. Viene considerato il numero più grande tra i due.
  • si calcola in seguito la dimensione di una riga della tabella in numero di byte. Si considera perciò il tipo interno associato ad ognuno dei tipi di dati dei campi della tabella. Un campo di tipo descrizione occupa 1 byte, un campo di tipo intero 2 byte, un campo di tipo intero lungo 4 byte, un campo di tipo decimale 8 byte. I campi di tipo alfanumerico e di lunghezza massima L occupano L+1 byte, moltiplicato per un coefficiente moltiplicatore che ha valore 1 se il database è in ASCII, e se ha il valore della variabile di ambiente STUSIZE se il database è UNICODE (in mancanza di valore, si assume 2). Bisogna notare che questa dimensione può essere ottenuta mediante la funzione Opzione / Informazioni accessibile in gestione delle tabelle.
  • si calcola comunque la lunghezza (in byte) di ogni indice, applicando le stesse regole di dimensionamento per i campi che lo compongono.
  • si calcola la dimensione globale della tabella moltiplicando il numero di righe per la dimensione di una riga, e applicando un coefficiente per tener conto del fatto che l'alimentazione non è mai totale (questo coefficiente vale 0,5 di default).
  • nel caso del database oracle, si definisce la dimensione del segmento iniziale prendendo la dimensione della tabella se è inferiore a 10 Mb. Altrimenti, si limita il segmento iniziale ad un valore dato dalla variabile di ambiente ADXEXTSIZE (espressa in K-byte). Questo valore non può in alcun caso essere superiore ad 1,5 Gbyte.