Modellazione dei dati

I tipi di campo dicono a Bobuild cosa rappresenta un valore. La modellazione dei dati decide come gli oggetti si collegano e quali pattern restano mantenibili man mano che l'app cresce. Questa guida integra Tipi di campo, Oggetti globali e Auto fields.

Parti dalla storia di business

Scrivi prima i sostantivi (Customer, Order, Ticket), poi i verbi (invia, approva, appartiene a). Ogni sostantivo che devi elencare, filtrare o gestire nei permessi separatamente di solito diventa un oggetto a sé.

Se stai migrando da un foglio di calcolo, vedi Da foglio di calcolo a Bobuild.

Uno-a-molti: Reference

Usa un Reference quando ogni figlio appartiene ad al massimo un genitore.

Genitore	Figlio	Il Reference sta su…
Customer	Order	Order → Customer
Request	Comment	Comment → Request
Job	Application	Application → Job

Nella pagina di dettaglio del genitore, aggiungi una griglia dei figli filtrata per quel reference. Nei form, il reference diventa un menu a tendina dei genitori.

Molti-a-molti: Reference Array

Usa un Reference Array quando entrambe le parti possono collegarsi a molti record e non ti servono campi extra sulla relazione stessa.

Esempi: progetto ↔ membri del team, articolo ↔ argomenti, ordine ↔ prodotti (quando ti serve solo sapere quali prodotti, non la quantità per riga).

Se il collegamento stesso ha dati (quantità, prezzo, ruolo nel progetto), crea invece un oggetto intermedio:

• OrderLine con reference a Order e Product, più quantity e unit_price
• ProjectMembership con reference a Project e Person, più role

Questo pattern scala meglio per report e Task.

Oggetti globali vs oggetti normali

Usa un oggetto global quando…	Usa un oggetto normale quando…
Deve esistere esattamente una riga	Ti servono molti record
I valori sono impostazioni a livello di app o profilo aziendale	Gli utenti creano/importano/eliminano righe
Template e Task devono sempre leggere la stessa fonte	Elenchi, code e portali navigano molti elementi

Abilita la modalità global solo su un oggetto vuoto. Vedi Oggetti globali.

Modellare utenti e ruoli

Gli utenti in Bobuild sono record ordinari di un oggetto che scegli per il login.

Pattern consigliato:

1. Oggetto Operator o User con email, password e name.
2. Un campo Choice o Multiple choice per i ruoli (Admin, Reviewer, Read-only).
3. Login rule che richiedono Active = true e i tag di ruolo corretti.
4. Oggetti separati per clienti o candidati quando hanno bisogno del proprio portale e non devono condividere la tabella dello staff.

Non mettere staff e utenti esterni nello stesso oggetto, a meno che i loro campi e il loro ciclo di vita non siano davvero identici.

Auto fields: pattern utili

• Etichetta di visualizzazione — espressione testuale che concatena nome + codice per menu a tendina più leggibili
• Rollup — conteggio/somma di record collegati (ticket aperti, totale ordine)
• Helper di stato — booleano "in ritardo" da formule su date
• Contesto copiato — porta l'e-mail del cliente sull'ordine per Task e-mail più semplici

Trappole comuni:

• Catene profonde di auto fields rallentano le scritture — preferisci formule poco annidate
• Disabilita gli auto fields durante import massivi, poi ricalcola (Settings)
• I filtri dentro i rollup devono corrispondere a come colleghi davvero i record

Checklist pratica

• Ogni elenco che ti interessa è un oggetto a sé (o un filtro chiaro su uno solo)
• Le relazioni usano Reference / Reference Array / oggetto di join in modo intenzionale
• Lo stato è un campo Choice con un insieme chiuso e piccolo di valori
• Le chiavi naturali usano l'unicità (da sola o insieme ad altri campi) dove i duplicati non devono esistere
• I segreti (password) esistono solo sugli oggetti di autenticazione
• La configurazione a livello di app sta in un oggetto global, non duplicata su ogni riga

Prossimi passi

• Recipes — brevi how-to (totali ordine, menu a tendina con prezzi, …)
• Tasks — automazioni sopra questo modello
• Panoramica sicurezza — portali, regole e autenticazione API
• Tutorial — blueprint completi che applicano queste scelte