[{"data":1,"prerenderedAt":133},["ShallowReactive",2],{"blog-it-database-per-cliente-multi-tenancy-1tool":3},{"id":4,"title":5,"body":6,"categories":113,"date":115,"description":12,"draft":116,"excerpt":117,"extension":118,"image":119,"lang":120,"meta":121,"modified":122,"navigation":123,"noindex":116,"path":124,"related":117,"seo":125,"seoDescription":126,"seoTitle":127,"slug":128,"sourcePath":129,"sourceRoute":117,"stem":130,"tags":117,"translated":116,"type":131,"wpId":117,"__hash__":132},"blog\u002Fit\u002Fblog\u002Fdatabase-per-cliente-multi-tenancy-1tool.md","Un database per cliente: come 1Tool risolve davvero il multi-tenancy",{"type":7,"value":8,"toc":103},"minimark",[9,13,18,21,25,28,32,35,39,64,68,85,91,95],[10,11,12],"p",{},"Quando più clienti utilizzano la stessa istanza di un software, un fornitore SaaS deve rispondere a una domanda fondamentale: come vengono separati i dati dei singoli clienti (tenant)? La risposta più diffusa nel settore è un database condiviso in cui ogni tabella ha una colonna aggiuntiva come “tenant_id”, usata per filtrare ogni interrogazione. Funziona, ma dipende interamente dal fatto che questo filtro sia implementato correttamente in ogni singolo punto del codice. 1Tool segue una strada strutturalmente diversa.",[14,15,17],"h2",{"id":16},"un-database-dedicato-per-cliente-invece-di-una-tabella-condivisa","Un database dedicato per cliente invece di una tabella condivisa",[10,19,20],{},"In 1Tool ogni cliente dispone di un proprio database, fisicamente separato. Il collegamento avviene dinamicamente in fase di esecuzione: quando un utente effettua l'accesso, il sistema sa con quale database del cliente deve comunicare e stabilisce la connessione di conseguenza. La separazione quindi non avviene a livello applicativo tramite una condizione di filtro, ma già a livello di infrastruttura. Un errore di programmazione che, con un database condiviso, potrebbe in teoria far dimenticare la condizione di filtro e rendere visibili i dati di un altro cliente è escluso fin dall'inizio con un'architettura rigorosa “un database per cliente”: semplicemente non esiste una tabella condivisa da cui si possano leggere per errore troppi dati.",[14,22,24],{"id":23},"server-dedicati-per-i-grandi-clienti-cache-separata-per-tutti","Server dedicati per i grandi clienti, cache separata per tutti",[10,26,27],{},"Se necessario, questa separazione può essere spinta ancora più in là. Per i clienti particolarmente grandi, 1Tool può persino assegnare un server di database completamente dedicato – con host e credenziali propri – invece di far girare il database sulla stessa infrastruttura di server condivisa con altri clienti. In questo modo l'isolamento passa dal livello logico a quello fisico dell'infrastruttura, quando ciò è sensato per un cliente per motivi di sicurezza o di prestazioni. Inoltre 1Tool gestisce anche la cache per singolo cliente: anche i dati memorizzati nella cache vengono tenuti separati per ogni cliente, così che nemmeno a questo livello possa verificarsi alcuna commistione tra clienti.",[14,29,31],{"id":30},"autorizzazioni-granulari-allinterno-del-cliente","Autorizzazioni granulari all'interno del cliente",[10,33,34],{},"La separazione tra clienti è solo uno dei livelli del controllo degli accessi. All'interno di un singolo cliente, un sistema di autorizzazioni con decine di regole di filtro specializzate – i cosiddetti scope – stabilisce inoltre quali singoli record un determinato utente può effettivamente vedere. Si può così fare in modo, ad esempio, che un commerciale veda solo i propri contatti, mentre un dirigente ha una panoramica completa – il tutto all'interno dello stesso database, già isolato per cliente.\nPer le aziende con requisiti elevati in materia di protezione e sicurezza dei dati, questa combinazione è un argomento rilevante nella scelta del fornitore. Un database condiviso con colonne tenant_id è più economico da scalare in esercizio, ma richiede che ogni singola interrogazione dell'intero sistema sia filtrata correttamente – per anni e attraverso molte generazioni di sviluppatori. Una vera architettura “un database per cliente” sposta questa garanzia dalla logica applicativa all'infrastruttura stessa.",[14,36,38],{"id":37},"domande-frequenti","Domande frequenti",[10,40,41,45,48,49,52,54,55,58,60,61],{},[42,43,44],"strong",{},"Un database per cliente significa che i dati sono archiviati fisicamente separati?",[46,47],"br",{},"\nSì, ogni cliente dispone di un proprio database separato invece di tabelle condivise con un identificativo del cliente come colonna di filtro.\n",[42,50,51],{},"È possibile gestire singoli clienti su un server completamente dedicato?",[46,53],{},"\nPer i clienti particolarmente grandi è possibile, con host e credenziali propri, separati dall'infrastruttura di server condivisa.\n",[42,56,57],{},"Come si stabilisce, all'interno di un cliente, chi vede quali record?",[46,59],{},"\nSe ne occupa un sistema di autorizzazioni con numerose regole di filtro specializzate, che si aggiungono alla separazione dei database e limitano l'accesso ai singoli record per ciascun utente.\n",[42,62,63],{},"Quanto è importante un vero isolamento dei database per i requisiti di protezione dei dati della vostra azienda?",[14,65,67],{"id":66},"continua-a-leggere","Continua a leggere",[69,70,71,79],"ul",{},[72,73,74],"li",{},[75,76,78],"a",{"href":77},"\u002Fit\u002Fblog\u002Fnotifiche-in-uscita-workflow-richiesta-http\u002F","Notificare altri sistemi: richieste HTTP direttamente dal workflow di automazione",[72,80,81],{},[75,82,84],{"href":83},"\u002Fit\u002Fblog\u002Fwebhook-in-entrata-dati-strutturati-nel-crm\u002F","Webhook in entrata: portare dati esterni nel CRM in modo strutturato",[10,86,87],{},[75,88,90],{"href":89},"\u002Fit\u002Frichiesta-di-appuntamento\u002F","Prenota una demo",[14,92,94],{"id":93},"leggi-anche","Leggi anche",[69,96,97],{},[72,98,99],{},[75,100,102],{"href":101},"\u002Fit\u002Fblog\u002Fagenti-ia-elaborazione-automatica-documenti\u002F","Agenti IA dietro le quinte: l'elaborazione automatica dei documenti",{"title":104,"searchDepth":105,"depth":105,"links":106},"",2,[107,108,109,110,111,112],{"id":16,"depth":105,"text":17},{"id":23,"depth":105,"text":24},{"id":30,"depth":105,"text":31},{"id":37,"depth":105,"text":38},{"id":66,"depth":105,"text":67},{"id":93,"depth":105,"text":94},[114],6064,"2026-06-27T09:00:00",false,null,"md","\u002Fmedia\u002F2026\u002F07\u002Fdatenbank-pro-mandant-multi-tenancy-1tool.jpg","it",{},"2026-07-25T08:25:52",true,"\u002Fit\u002Fblog\u002Fdatabase-per-cliente-multi-tenancy-1tool",{"title":5,"description":12},"Un database dedicato per ogni cliente invece di tabelle condivise: come 1Tool risolve il multi-tenancy a livello di infrastruttura.","Un database per cliente: multi-tenancy in 1Tool | 1Tool","database-per-cliente-multi-tenancy-1tool","\u002Fit\u002Fblog\u002Fdatabase-per-cliente-multi-tenancy-1tool\u002F","it\u002Fblog\u002Fdatabase-per-cliente-multi-tenancy-1tool","posts","2p4oei0S80e5vJQxsq1wIL7hQpPIUrgG6P8M2J6demk",1791582096501]