Programma Ge.Co.J studio archivio

L’anno nuovo è arrivato , e io sempre in solitaria sto portando avanti il progetto del programma Ge.Co.J procedono con i vari compiti che lo stato del lavoro richiede.  Attualmente la versione  è 0.473.72a ( per capire cosa vuol dire il numero della versione leggete questo articolo ).

In questo articolo parliamo dell’archivio dove verranno salvate e lette tutte le informazioni , con “Archivio” si intende il file dove il programma archivia  le informazioni , non mi dilungo a spiegarvi i principi dei vari tipi di archivi per non stare a scriver un articolo dedicato alla spiegazione delle varie tipologie.

Nello studio della tipologia più consona dell’archivio è stato scelto un archivio SQL basato su file e non su server.
Si è scelto di utilizzare una struttura a file cosi che non sia richiesta la presenza di ingombranti Servizi SQL installati nel computer per poter gestire le informazioni , rendendo di conseguenza la gestioni delle informazioni su uno o più file cosi che  l’applicazione può essere resa portabile e non appesantire il computer.
La struttura SQL è stata una scelta personale basata sulle mie competenze e per la sua semplicità nella scrittura e richiesta delle informazioni con semplici Query basate sullo Standard SQL.

Ideazione Ipotetica del tabelle per l’archiviazione delle informazioni, ho scritto “Ipotetica” perché durante lo sviluppo dell’applicazione la struttura degli archivi può ricevere modifiche a seconda delle necessità che si presenteranno.

Ora pensiamo di cosa abbiamo bisogno, io direi il primo punto è di un archivio con comprenda “componenti” , “produttore” , “venditore” , “posizione” ma vedo subito una aggiunta da eseguire , infatti parlando di componentistica elettronica abbiamo la dicitura dell’ingombro dei componenti e siccome è più componenti possono avere lo stesso ingombro mi ritrovo alla fine una lista di ingombri.  Avendo una Lista preferisco che esista una nuova tabella dedicata a queste informazioni , cosi da avere un riferimento di ingombri e non dover scrivere per ogni componente il tipo di ingombro e stesso succede per il capo “Tipologia”.

Detto questo avremmo le tabelle per “componenti” , “produttore” , “venditore” , “posizione”, “tipologia”, “ingombro” , ma ideando cosa debba fare il programma mi rendo conto che ho molte più informazioni di varia natura a seconda della tipologia del componente, pertanto mi adopero per creare una strutta che mi permetta di avere un salvataggio di più informazioni di avario tipo senza dover creare nella tabella “componenti” tanti campi quanti sono i dati ipotetici da inserire , in più rendendo la struttura dinamica mi libero da possibili modifiche dell’archivio per l’aggiunta di possibili aggiunte future.

Per eseguire l’aggiunta di una struttura dinamica ho ideato una nuova tabella che al suo interno sarà abbinata al componente di riferimento ma che permetterà di aggiungere la descrizione del campo in questione e il suo contenuto. Studiando poi le varie tipologie di informazioni ho eseguito questa procedura anche alle tabelle del produttore e del venditore.

Per completare ho aggiunto anche la tabella dei movimenti per avere uno storico delle entrate e uscite di ogni componente.
Avendo ideato il database creo il file di quest’ulimo cosi da poterci lavorare con le prove va vado a fare dall’applicativo, il database ha in tutto 10 tabelle e per prassi ho creato il database di prova con tutti nomi di queste tabelle e i relativi campi con le diciture in lingua inglese.