Finalmente riesco a risponderti... tutte le volte che ero al pc, me ne scordavo.
Allora, magari sono dati che non cambieranno mai (nel senso, che non servirà aggiungerli o toglierli dall'insieme che gestisci) ma io lo prevederei.
Gestirei il tutto con un database; considerando il tipo di applicazione, ti direi di partire con SQLite. Così lo porti in giro con l'applicazione e ti eviti installazioni e dipendenze varie da gestire.
Andresti a popolare le tabelle del tuo database con tutti i dati che ci sono li presenti. Potrebbe non essere proprio immediata come struttura; in generale per ogni record (riga di dati nella tabella del db) dovrai popolare tutti i campi che hai nella prima colonna (pressione, trazione parallela etc etc). Queste saranno di fatto le tue colonne della tabella del db.
Quindi sia il "codice" (C14, C16 etc etc) che le voci della prima colonna, saranno colonne del tuo database. Quando l'utente sceglie C18, tu farai una cosa tipo (esempio):
(il nome della tabella lo darò poco sensato immagino, non conoscendo di che si tratta nello specifico)
SQL:
SELECT * FROM tbl_resistenze WHERE codice='C20';
Puoi anche avere un tipo di struttura diversa, dipende da come vuoi impostare i tuoi dati. Ti potrebbe servire una colonna ulteriore per capire la "tipologia" (salvata come id numerico), che andrà mappata in un'altra tabella ("pioppo e conifere", "latifoglie" etc. dipende se ti serve come dato anche).
Un'altra alternativa: ti fai una tabella con i "codici" (C14, C16 etc) ed eventualmente altre proprietà che ti servono (e qui ci aggiungi la "tipologia" di cui sopra) e poi nell'altra tabella setti le specifiche associandole al codice. Questa tabella avrà come colonne ciò che hai nella colonna 1 nella prima immagine; in più avrà come colonna il "codice", tipo "id_codice", che sarà l'ID dell'elemento nella tabella codici.
Quest'ultimo che ti ho descritto è meglio del primo. In questo caso per tirar fuori i dati di C20, farai tipo:
SQL:
SELECT * FROM tbl_resistenze WHERE id_codice=4;
se ti servono i dati della "tabella dei codici" dovrai fare una join, eg tipo:
SQL:
SELECT * FROM tbl_resistenze JOIN tbl_codici ON tbl_codici.id = id_codice WHERE id_codice=4;
(sono un pò arrugginito non tocco SQL da 1 annetto buono :D ma penso sia corretto anche sintatticamente)
Ad ogni modo un database lo devi avere, scordati di memorizzare tutto senza un DB. Questo vale anche se ti fai un'applicazione web, come suggerito da bigendian: in questo caso puoi usare MySQL..
E' MOLTO più veloce e semplice se fai un software web con backend in PHP (per esempio) e con grafica HTML+CSS (+ JS) rispetto a un software in C#, però dipende quanto conosci già le librerie grafiche con quest'ultimo.
Il vantaggio di avere un DB è anche in caso di aggiunta di un "C100", lo puoi fare molto semplicemente (puoi fare anche una parte del sw dedicata proprio alla gestione di queste tabelle interne).
Io ho immaginato questo tipo di struttura, ma considera che se hai tabelle identiche con i medesimi dati (colonne del db) puoi anche usare strutture diverse per gestire i dati; dipende bene cosa dovrai memorizzare. Ti consiglio di studiare anche SQL comunque, se non lo conosci.
Ah, in merito al non dare al cliente i dati, la cosa migliore è stare sul web: il tutto sarebbe gestito dal backend, quindi il cliente non potrebbe fare nulla (mi ero perso questa parte, sorry).
PS: non l'ho precisato, ma se ogni riga è calcolata mediante formule, allora ti basta il primo valore, così il cliente non sa che formula usi (e puoi fare il db locale e darlo al cliente, tanto solo del primo valore non saprebbe che farsene). In tal caso però puoi anche ripensare la cosa evitando un database.
Tieni a mente che reversare un programma in C# se non protetto è un gioco da ragazzi comunque.
