C'è qualche motivo per impedire agli sviluppatori di avere una copia locale del database nella loro macchina?

A volte hai un ambiente aziendale in cui lo sviluppo è solo lato client e i database sono il regno dei DBA. In questi casi, gli sviluppatori avranno ancora un'istanza di sviluppo comune su cui lavorare anche se non possono apportare modifiche, possono comunque riempirlo con dati di merda per il test. Se il tuo DB è un mainframe o un minicomputer, è probabile che l'API per accedervi sia tramite stored procedure piuttosto che SQL semplice, nel qual caso nascondere lo schema sottostante è ok in quanto gli sviluppatori non hanno bisogno di saperlo - hanno bisogno per conoscere gli sprocs comunque.

Per inciso, anche se hai degli sviluppatori con DB locali che usano, vale ancora la pena avere un server DB centralizzato che ospita l'ultima versione o anche solo un DB di integrazione, quindi gli sviluppatori possono testare il loro codice contro un DB di stato noto con buoni (o ragionevoli) dati in esso.

Il secondo aspetto è la sicurezza del codice. Lavoravo per un'azienda del settore dei servizi finanziari che prendeva molto sul serio la sicurezza, i nostri sviluppatori offshore lavoravano sul codice solo tramite RDP sui computer che erano ospitati nell'ufficio locale. Il mio laptop è stato bloccato per impedire l'uso di filesharing e siti di posta elettronica e cose come le porte USB sono state disabilitate. Penso che questo sia richiesto per l'accreditamento di sicurezza PCI.

Se hai Devs e DBA invece di solo Devs, dovresti probabilmente permettere agli sviluppatori di accedere al DB tramite SProcs. e quindi la conoscenza dello schema sottostante non è necessaria. È possibile creare un DB di test che restituisca sempre i dati statici in risposta alle chiamate sproc e la velocità di Dev non sia influenzata (forse addirittura migliorata!)

Tuttavia, secondo la mia esperienza, anche se un'azienda ha un team DBA separato, di solito i Devs che scrivono gli sprocs e gli schemi di tabella ecc. che vengono poi trasferiti ai DBA che si occupano dell'infrastruttura / backup / indicizzazione del DB ecc.

In questo caso è ridicolo nascondere lo schema agli sviluppatori che lo stanno scrivendo.

Inoltre, non sono sicuro che si ottenga alcun beneficio per la sicurezza nascondendo lo schema. O anche il codice sorgente! A meno che tu non abbia un prodotto molto tecnico e all'avanguardia (nel qual caso devi brevettare gli algoritmi) Chiunque può programmare una versione migliore in pochi mesi.

In effetti, se il tuo prodotto è buono, probabilmente puoi già scaricare una versione open source gratuitamente.

Il valore di una società di software è la base di utenti e i nomi protetti da copyright. Non è il suo codice.

Rispondi alla domanda riscritta: i Devs dovrebbero essere consentiti Database locali

OK, supponendo che i tuoi sviluppatori creino lo schema del database non c'è differenza (sicurezza) tra codice e schema DB.

es. Dovresti avere un progetto DB e mantenere lo schema in un sistema di controllo del codice sorgente. Avere un DB locale è solo un'implementazione dello schema e non aumenta il rischio.

Ora puoi affermare che non avere un codice sorgente localmente su un laptop che viene portato fuori dall'edificio è un vantaggio per la sicurezza. Anche se ti fidi dei tuoi computer, i laptop vengono persi / rubati tutto il tempo.

Ma questo non è davvero un argomento a favore o contro i DB di sviluppo locali vs è un argomento per non portare a casa i computer di sviluppo. Quale, a meno che tu non abbia persone che lavorano da casa, perché dovresti?

Se hai lavoratori in remoto, allora sì puoi affrontare i problemi di sicurezza relativi ai computer rubati che rilasciano informazioni confidenziali. ma sarei molto più preoccupato dei dati / email dei clienti confidenziali, piuttosto che dello schema sourcecode / db schema