Se si dispone di un database diverso per cliente in quanto non è necessario condividere i dati tra loro, lo stesso vale se un cliente ha più negozi?
Credo che sia più facile fare query per le statistiche (alcune richiedono 4-6 join tabella) se si trovano su un singolo schema anziché su più schemi.
Ma tutti (non hanno ancora fatto nulla) in team credono che le query a schema incrociato siano la strada da percorrere. Sostengono che Postgres lo supporta bene.
Qual è la strada da percorrere?
Separare i client per database ha senso: sicurezza, gestire in modo univoco backup / ripristini, personalizzazioni.
Avere ciascuna posizione sotto uno schema separato ti darebbe dei modi per: raggruppare oggetti, sicurezza ed eventualmente gestire backup separati, ma a meno che tu non veda altri modi per ottenere questa separazione, penso che rendere le query e la manutenzione inutilmente difficili.
Sembra più facile avere posizioni gestite dai dati. Puoi sempre gestire la sicurezza della selezione dei record disponendo di una tabella di sicurezza che indica le posizioni a cui un utente può accedere.
Potresti ritenere che ci siano poche query / rapporti che combinano le posizioni in questo momento, ma una volta che un cliente riceve un rapporto che esegue questa operazione, ne vorranno di più. Questi clienti di solito pagano commissioni di licenza più elevate e eserciteranno ulteriore pressione sul team di vendita (il che comporterà una pressione ancora maggiore sul team di sviluppo.)
Leggi altre domande sui tag sql database database-design