Progettazione 4D: una guida completa all'architettura

La progettazione architettonica 4D è il processo di strutturazione di un database 4D (le sue tabelle, campi, relazioni, indici e livelli di accesso) in modo che l’applicazione rimanga veloce, gestibile e sicura man mano che cresce. Uno schema 4D ben pianificato implica in genere cinque decisioni fondamentali: granularità della tabella, strategia di relazione, tipo di chiave primaria, posizione dell’indice e separazione dei dati dalla logica dell’interfaccia. Gestirlo fin dall’inizio ti aiuterà a evitare costose migrazioni in futuro.

Punti chiave

• La progettazione dell’architettura 4D separa tre aspetti: il modello dati (tabelle, campi, relazioni), il livello della logica aziendale (metodi, classi, trigger) e il livello di presentazione (moduli, caselle di riepilogo, finestre di dialogo).
• Il tipo di relazione conta più del numero di tabelle: un collegamento molti-a-molti necessita di una tabella di giunzione, mentre un collegamento uno-a-molti utilizza un campo chiave esterna più una relazione.
• Gli indici velocizzano le letture ma rallentano le scritture: indicizza le chiavi esterne e qualsiasi campo utilizzato nella clausola WHERE di una query, non tutti i campi.
• Il livello ORDA (Object Relational Data Access) di 4D cambia il modo in cui pensi allo schema: tabelle e campi con nomi ben definiti diventano classi di dati leggibili e nomi di attributi nel codice.
• La distribuzione client-server rispetto a quella per utente singolo è una decisione architettonica, non un ripensamento della distribuzione: influisce sul blocco, sulla memorizzazione nella cache e sul modo in cui si scrivono le query.
• Le convenzioni di denominazione applicate in modo coerente fin dal primo giorno consentono di risparmiare più tempo di refactoring rispetto a qualsiasi altra singola abitudine.

Cosa significa “architettura 4D” nel contesto di un database

La progettazione dell’architettura 4D si riferisce alla progettazione strutturale di un’applicazione costruita sulla piattaforma 4D (4th Dimension), il database relazionale e l’ambiente di sviluppo low-code originariamente rilasciato dal team di Laurent Ribardière nel 1984 e ora gestito da 4D SAS. A differenza di un database SQL puro, 4D raggruppa il motore dati, un linguaggio di programmazione, un progettista di moduli e un server web/REST in un unico prodotto, quindi l‘“architettura” qui abbraccia sia lo schema che i livelli dell’applicazione su di esso.

Il termine viene talvolta confuso con la visualizzazione architettonica (4D BIM, tempo come quarta dimensione nella progettazione edilizia). Questa guida copre il senso del software: come strutturare un database 4D e i suoi livelli di applicazione. Se sei arrivato cercando la progettazione di un edificio, i concetti seguenti non si applicheranno.

I tre livelli di un’applicazione 4D

I progetti di progettazione architettonica 4D beneficiano di un modello a strati esplicito. La suddivisione delle responsabilità impedisce a un’app in crescita di trasformarsi in un groviglio di script di moduli.

Livello 1: il modello dei dati

Il modello dati è l’insieme di tabelle, campi, relazioni e indici memorizzati nel file della struttura 4D. Questo livello non dovrebbe contenere codice di interfaccia utente né regole aziendali che potrebbero vivere altrove. I tipi di campo (testo, intero, reale, data, ora, booleano, blob, oggetto, immagine) e le lunghezze dei campi sono fissi qui e modificarli successivamente su un database attivo richiede attenzione.

Livello 2: logica aziendale

La logica aziendale risiede nei metodi di progetto, nelle classi e nei trigger di tabella. Nella moderna 4D, le classi (introdotte con 4D v18 R3 e successivamente ampliate) consentono di scrivere codice riutilizzabile e testabile anziché disperdere la logica tra i metodi del modulo. Un trigger su una tabella si attiva durante la creazione, il salvataggio e l’eliminazione: utile per gli audit trail, ma un trigger che richiama l’interfaccia utente si interromperà nei contesti del server headless.

Correlato: Claris FileMaker Pro — La piattaforma di database relazionale di lunga durata per i team che necessitano di app personalizzate su desktop, Web e dispositivi mobili da un singolo file..

Livello 3: Presentazione

La presentazione copre moduli, caselle di riepilogo, finestre di dialogo di input e qualsiasi output Web o REST. I moduli 4D si legano direttamente a campi e variabili, il che è conveniente ma incoraggia a inserire la logica nel modulo. Mantenere i metodi dei moduli sottili, chiamando un metodo di classe e visualizzando il risultato, è la più grande vittoria in termini di manutenibilità nella maggior parte dei progetti 4D.

Progettare il modello dei dati: tabelle, relazioni e chiavi

Le decisioni sulla modellazione dei dati nella progettazione dell’architettura 4D seguono principi relazionali, con meccanismi specifici 4D sovrapposti.

Scelta della granularità della tabella

Una tabella dovrebbe rappresentare un tipo di entità. Dividere una tabella “cliente” in “cliente” e “indirizzo_cliente” ha senso quando un cliente può avere diversi indirizzi; unirli ha senso quando c’è esattamente un indirizzo per cliente e nessun riutilizzo. L’eccessiva normalizzazione in molte tabelle di piccole dimensioni aumenta il numero di relazioni e join, con un impatto negativo sulle prestazioni nelle visualizzazioni elenco.

La nostra scelta: Airtable — Un'interfaccia semplice come un foglio di calcolo posizionata sopra un vero database relazionale, con automazioni, visualizzazioni e interfacce condivisibili..

Tipi di relazione

4D supporta le relazioni automatiche definite nell’editor della struttura e le relazioni manuali create nel codice. I modelli comuni:

Relazione	Implementazione 4D	Uso tipico
Uno a molti	Campo chiave esterna sul lato “molti” più una relazione	Fattura → Righe fattura
Molti-a-molti	Tabella di giunzione con due chiavi esterne	Prodotti ↔ Fornitori
Uno a uno	Chiave primaria condivisa o chiave esterna univoca	Utente → Profilo utente
Autoreferenziazione	Chiave esterna che punta alla stessa tabella	Impiegato → Direttore

Strategia della chiave primaria

4D offre chiavi primarie Longint con incremento automatico e chiavi primarie UUID (testo). Le chiavi Longint sono compatte e veloci da indicizzare; Gli UUID sono univoci a livello globale, il che è importante quando si uniscono dati da più siti o si sincronizzano con sistemi esterni. Un compromesso comune è una chiave interna longint più un campo di testo separato e univoco di “riferimento esterno”.

Indicizzazione e prestazioni delle query

Gli indici rappresentano la leva prestazionale più efficace nella progettazione dell’architettura 4D e anche la più semplice da applicare in eccesso.

Cosa indicizzare

Indicizza qualsiasi campo utilizzato come chiave esterna di una relazione, qualsiasi campo utilizzato frequentemente nei criteri di ricerca di una query e qualsiasi campo utilizzato per l’ordinamento in caselle di riepilogo di grandi dimensioni. 4D supporta indici B-tree standard, indici di parole chiave per ricerche di testo basate su parole e indici compositi che coprono più campi.

Cosa non indicizzare

Ogni indice aggiunge costi di scrittura e archiviazione. Indicizzare un campo booleano con due possibili valori raramente aiuta. L’indicizzazione di un campo che viene letto sempre e solo come parte di una visualizzazione completa del record aggiunge un sovraccarico senza alcun guadagno. Esaminare gli indici dopo che l’applicazione ha modelli di utilizzo reali anziché fare ipotesi in anticipo.

Strategia delle query

Le query ORDA (ds.Invoice.query("Status = :1"; "Open")) sono generalmente preferibili ai classici comandi QUERY per il nuovo codice perché restituiscono selezioni di entità che possono essere ordinate, filtrate e passate tra metodi senza ripetere la query. Per tabelle molto grandi, limitare la query con criteri indicizzati prima di applicare filtri non indicizzati mantiene prevedibili i tempi di risposta.

Correlato: Knack — Un generatore di database senza codice rivolto a portali, directory e strumenti interni, con prezzi forfettari anziché tariffe per utente..

ORDA e l’architettura moderna 4D

ORDA (Object Relational Data Access) è il livello di accesso ai dati orientato agli oggetti di 4D, introdotto in 4D v17. Espone le tabelle come classi di dati e i record come entità, quindi una tabella denominata “Invoice” diventa “ds.Invoice” e un campo denominato “TotalNet” diventa “$invoice.TotalNet”.

Ciò ha una conseguenza architetturale per la progettazione dell’architettura 4d: i nomi delle tabelle e dei campi ora fanno parte della tua API pubblica. Rinominare un campo interrompe il codice in modo visibile in fase di compilazione, ma la denominazione incoerente rende difficile la lettura del codice ORDA. Adottare una convenzione – nomi di tabelle singolari, campi PascalCase, nessuna abbreviazione – ripaga immediatamente.

ORDA supporta anche selezioni di entità lato client che vengono caricate solo parzialmente, il che modifica il profilo delle prestazioni delle schermate di elenco. Una casella di riepilogo associata a una selezione di entità può visualizzare migliaia di righe senza caricare tutti i record, presupponendo che la query dietro di essa sia indicizzata.

Se stai facendo acquisti: Zoho Creator — Un generatore di app a basso codice che si collega alla più ampia suite Zoho e prezzi per utente anziché per app..

Distribuzione client-server, utente singolo e Web

La topologia di distribuzione modella la progettazione dell’architettura 4D più di quanto molti sviluppatori si aspettino.

Le applicazioni utente singolo eseguono il motore dati e l’interfaccia in un unico processo. Il blocco è banale; l’ottimizzazione delle prestazioni riguarda principalmente la velocità del disco locale.

Client-server divide il server 4D (motore dati) dal client 4D (interfaccia). I record vengono bloccati sul server e il costo di andata e ritorno sulla rete di ciascuna query diventa significativo. Le architetture che emettono molte piccole query per schermo funzionano male in questo caso; l’invio in batch di query e l’utilizzo delle selezioni di entità riducono i viaggi di andata e ritorno.

La distribuzione Web e REST espone lo stesso modello di dati tramite il server REST di 4D o tramite metodi Web compilati. La sicurezza passa in primo piano: l’accesso alle tabelle e ai campi deve essere limitato tramite ruoli e privilegi e qualsiasi regola aziendale applicata solo in un metodo di modulo viene effettivamente non applicata per i client Web.

Convenzioni di denominazione e documentazione

La denominazione coerente non è affascinante ma decisiva per la progettazione dell’architettura 4D. Una convenzione praticabile per il 4D:

• Tabelle: nomi singolari, PascalCase (“Cliente”, “InvoiceLine”).
• Campi: PascalCase, senza prefissi di tipo (“InvoiceDate”, non “dInvDate”).
• Relazioni: denominate in base alla tabella di destinazione (“Customer_Invoices”).
• Metodi: primo verbo (“CreateInvoice”, “RecalculateTotals”).
• Classi: prima il nome (“InvoiceService”, “TaxCalculator”).

Documentare lo schema, anche sotto forma di un singolo file Markdown che elenca ciascuna tabella, il suo scopo e le sue relazioni chiave, semplifica notevolmente l’onboarding e le migrazioni future. L’editor della struttura di 4D mostra graficamente le relazioni, ma non spiega perché esiste una tabella.

Errori comuni nella progettazione dell’architettura 4D

Inserimento della logica aziendale nei metodi del modulo. I metodi del modulo non possono essere richiamati da contesti Web o attività pianificate, quindi la logica intrappolata lì deve essere duplicata.

Utilizzo di comandi classici basati sulla selezione nel nuovo codice. Le selezioni classiche sono legate al processo e non viaggiano bene tra i processi; Le selezioni delle entità ORDA sono più flessibili.

Saltare la tabella di giunzione. La memorizzazione di più valori in un singolo campo di testo (ID separati da virgole) impedisce l’indicizzazione e rende problematico il reporting.

Indicizzazione di tutto. Le prestazioni di scrittura peggiorano e il vantaggio viene raramente realizzato.

Ignorare i privilegi fino alla distribuzione. Adattare un modello di sicurezza a un’applicazione finita è molto più difficile che progettarlo insieme allo schema.

Come decidere: una lista di controllo pratica

Prima di realizzare il tuo progetto di architettura 4D, risolvi queste domande:

1. Quanti utenti simultanei si connetteranno tramite LAN, WAN o Web?
2. Quali entità hanno una relazione naturale uno-a-molti e quali necessitano di tabelle di giunzione?
3. Quali campi verranno visualizzati nei criteri di ricerca o nell’ordinamento su tabelle di grandi dimensioni?
4. Quali regole aziendali devono valere indipendentemente dal punto di ingresso (modulo, web, importazione)?
5. I dati verranno mai uniti con un altro sistema, richiedendo chiavi UUID?
6. Chi lo manterrà tra due anni, e la denominazione avrà senso per loro?

Le risposte a queste sei domande determinano la maggior parte delle decisioni strutturali in un progetto 4D.

Ulteriori letture

La documentazione ufficiale 4D su Developer.4d.com copre ORDA, classi, privilegi e distribuzione in dettaglio. Per i fondamenti della modellazione relazionale che si applicano indipendentemente dalla piattaforma, vedere l’articolo di Wikipedia sulla normalizzazione del database. Per il contesto più ampio delle piattaforme di sviluppo rapido e low-code di applicazioni, la voce di Wikipedia sulle piattaforme di sviluppo low-code è un punto di partenza ragionevole. 4D SAS pubblica anche note di rilascio e guide alla migrazione che descrivono quando sono state introdotte ORDA, classi e altre funzionalità di progettazione dell’architettura 4d.

Domande frequenti

Cos’è la progettazione dell’architettura 4D?

La progettazione dell’architettura 4D è il processo di pianificazione della struttura di un’applicazione 4D (4th Dimension): le sue tabelle, campi, relazioni, indici, livello di logica aziendale e livello di presentazione. Determina le prestazioni dell’applicazione, la facilità con cui può essere modificata e la sicurezza con cui può essere distribuita su desktop, client-server o client Web.

L’architettura 4D è uguale al BIM 4D?

No. Il BIM 4D aggiunge il tempo come quarta dimensione al Building Information Modeling per la pianificazione della costruzione. L’architettura 4D nel senso del software si riferisce alla progettazione di applicazioni sulla piattaforma di database 4D. I due campi condividono un’abbreviazione ma nient’altro.

Dovrei usare ORDA o i classici comandi 4D?

ORDA è l’opzione migliore per i nuovi sviluppi. Restituisce selezioni di entità che possono essere passate tra metodi, ordinate e filtrate senza bisogno di essere nuovamente interrogate ed espone tabelle e campi come proprietà di oggetti leggibili. I classici comandi basati sulla selezione sono ancora utili nel codice legacy e in alcuni casi speciali.

Quanti indici dovrebbe avere una tabella 4D?

Non esiste un numero fisso. Indicizzare le chiavi esterne, i campi utilizzati nei criteri di ricerca comuni e i campi utilizzati per ordinare elenchi di grandi dimensioni. Evita di indicizzare campi con cardinalità bassa, come valori booleani o campi di stato con due o tre valori, poiché il costo di scrittura di solito supera il vantaggio di lettura.

Quale tipo di chiave primaria dovrei scegliere in 4D?

Le chiavi longint con incremento automatico sono compatte e veloci e si adattano alle applicazioni a sito singolo. Le chiavi di testo UUID sono più grandi ma univoche a livello globale, il che è importante quando si uniscono dati da più siti o si integrano con sistemi esterni. Molti progetti utilizzano internamente una chiave longint più un campo di riferimento esterno univoco.

Posso modificare il modello dati 4D dopo la distribuzione?

Sì, ma con attenzione. L’aggiunta di tabelle, campi e indici è generalmente semplice. La modifica dei tipi di campo, la ridenominazione dei campi utilizzati dal codice ORDA o la ristrutturazione delle relazioni su un database attivo richiedono una migrazione pianificata, idealmente testata prima su una copia dei dati di produzione.