Sviluppare una soluzione in FileMaker: campi e tabelle

Introduzione

In questa serie di articoli ci stiamo occupando di metodo di sviluppo, ovvero di quanto sia determinante essere scrupolosi, ordinati e metodici nel momento in cui progettiamo applicazioni di una certa complessità. Seguire un metodo in fase di progettazione non è un problema di estetica o di forma, ma un punto di sostanziale importanza a fini pratici.

In questo articolo ci occuperemo di campi e tabelle, degli standard di nomenclatura e di come evitare che campi calcolati troppo complessi possano risultare incomprensibili.

Le tabelle

Cominciamo quindi dalle tabelle. Quando si inizia a costruire un’applicazione la prima cosa da fare è costruire le tabelle e assegnare loro un nome. Operazione apparentemente banale, se non fosse che quel nome ce lo porteremo dietro per tutto lo sviluppo: se per caso dovesse essere inadeguato, troppo lungo o poco comprensibile saremo comunque costretti ad averci a che fare qualche migliaio di volte.

Il nome delle tabelle sarà scontato nel caso si tratti di Articoli, Clienti, Fatture, Progetti e degli archivi principali di un’applicazione, ma la scelta potrebbe rivelarsi un po’ più complicata nel caso delle tabelle secondarie, come ad esempio le tabelle di collegamento che ci servono per creare relazioni molti a molti. In questo caso vale la pena perdere qualche minuto per cercare un nome che non sia troppo criptico ma nemmeno troppo lungo (un nome lungo ci darebbe fastidio nei campi calcolati, nel grafico delle relazioni e in alcune finestre di FileMaker).

Prendiamo l’esempio di una tabella che contenga l’ID agente e l’ID azienda, utile nel caso in cui un’azienda abbia molti agenti ed ogni agente sia collegato a diverse aziende. Come nominare una tabella del genere? In questo caso, un nome come TabellaDiCollegamentoAgentiAziende è formalmente corretto, ma certamente non è l’ideale. Meglio optare per un più freddo ma efficace tabAgeAzi, o tabAgentiAziende.

Fortunatamente, il numero delle tabelle in un’applicazione non è mai spropositato, nè capita tutti i giorni di aggiungerne di nuove. Ci possiamo quindi permettere di sprecare un po’ di energia mentale per trovare il nome che riteniamo più idoneo e comprensibile in previsione del lavoro da svolgere.

A proposito di comprensibilità: le tabelle non prevedono l’aggiunta di commenti, che in questo caso tornerebbero utili per ricordarci che i record di quella tabella vengono creati ed eliminati via script, o per mostrarci un determinato report del quale non ricordiamo nemmeno l’esistenza. Come al solito non ci arrendiamo: il suggerimento è di creare un campo all’interno della stessa tabella, nominandolo ad esempio

___record_del_calendario_pazienti

I tre underscore iniziali servono a mantenere il campo in cima alla lista ordinata alfabeticamente, mentre il nome stesso del campo diventa il commento. Sembra banale, ma nel caso di un’applicazione complessa può essere davvero utile avere qualcosa che ci ricordi al volo la funzione della tabella, magari mentre selezioniamo il campo per inserirlo in un layout o all’interno di uno script.

I campi

Discorso più complesso riguarda lo standard di nomenclatura dei campi, i quali ovviamente possono essere tantissimi, e dove bisogna assolutamente trovare una regola da seguire che ci consenta di nominarli efficacemente e rapidamente mantenendo una certa coerenza all’interno dell’applicazione.

FileMaker, si sa, è buono e accetta nomi di tutti i generi, semplicemente avvertendovi che forse sarebbe meglio non usare determinati caratteri nel nome del campo. Per questo molti sviluppatori, approfittando di questa apparente bontà, non si pongono nemmeno il problema di come nominare un campo. Ciò che questi sviluppatori ignorano è che la punizione divina è dietro l’angolo, pronta ad abbattersi nel momento in cui si troveranno ad avere a che fare con qualche centinaio di campi nominati tipo riassunto totale somma fattura new new copia 2 (ma se ne vedono anche di peggio).

Il consiglio è quindi di scegliersi gli standard in base al tipo di campo ed all’utilizzo che ne sarà fatto. Gli standard comunemente usati  per i campi dagli sviluppatori FileMaker prevedono l’utilizzo di un suffisso che ne consenta facilmente il riconoscimento, oltre alla possibilità raggrupparli in ordine alfabetico. 

Alcuni dei suffissi più comuni:

c_calcolato
g_globale
s_summary (o se preferite r_ che sta per riassunto) 
i_interfaccia
z_campi sviluppatore

Qual è il senso di questi standard?

Innanzitutto identificare i campi globali e i campi calcolati ci permette di evitare errori durante la compilazione degli script. Per esempio, se cercherò di cambiare il valore via script del campo c_nome, risulterà evidente che sto compiendo un errore, visto che c_nome è un campo calcolato.

Ma non è finita qui. Ci sono diversi altri casi per i quali vale la pena assegnare dei nomi che consentano l’identificazione, per esempio quello delle chiavi per le relazioni:

pk_campo: primaryKey (chiave primaria, quindi l’identificativo del record della tabella)
fk_campo: foreignKey (chiave esterna, quindi l’identificativo del record di una tabella correlata)

Un esempio pratico: se ci troviamo nella tabella ordini la mia chiave primaria potrà essere

pk_recId

ma poichè l’ordine è sempre legato ad un cliente, nella stessa tabella avrò il campo

fk_cliente

che conterrà l’ID record del cliente e sarà relazionato al campo pk_recId della tabella clienti. Questo significa poter impostare delle relazioni “sicure”, senza la necessità di verificare che i campi relazionati siano quelli giusti, cioè che contengano davvero i dati che ci aspettiamo.

Un’ultima nota sui commenti: nella definizione dei campi è previsto l’inserimento di un commento, anche se qualche volta, nel caso di calcolati complessi, potrebbe servire inserire qualche riga direttamente nel calcolo stesso facendolo precedere dal doppio slash. Nell’esempio che segue il commento serve a spiegare in quali casi il campo che indica lo stato di un ordine debba assumere il valore di 1, 2, 3 o 4.


Sempre a proposito di campi calcolati, è fondamentale fare in modo che anche i calcoli siano leggibili: al di là del fatto che il calcolo funzioni, non bisogna mai escludere l’eventualità di doverci rimettere mano. In questo caso sarà utilissima la funzione Let, che grazie all’uso delle variabili fa sì che anche un calcolo di una certa complessità diventi facile da interpretare.

Per ora ci fermiamo qui, riservandoci di tornare in futuro sull’argomento standard dei campi, che meriterebbe un approfondimento a parte.

Conclusioni

Anche in questo articolo ci siamo occupati di metodo di sviluppo, e ancora una volta abbiamo sottolineato come l’essere ordinati in fase di progettazione non debba essere vissuto come un fastidio o un’inutile perdita di tempo, ma faccia parte di un metodo che ci consentirà di intervenire con tranquillità anche ad anni di distanza. 

Per concludere vi invitiamo a meditare sul fatto che sviluppare con metodo, oltre a consentire a terzi di intervenire facilmente in caso di risoluzione di problemi o di ulteriori implementazioni, rappresenta un valore aggiunto per le applicazioni e possa essere considerato la linea di demarcazione tra uno sviluppatore hobbista ed uno professionale.

Ti è mai capitato di buttare all’aria settimane di lavoro per un errore in fase di progettazione? Qual è il tuo metodo in fase di sviluppo? Raccontaci la tua soluzione e condividi le tue idee con gli altri Guru: scopri la comunità Filemaker su Guru Corner!