Ho una domanda riguardante l'uso appropriato degli schemi di database di SQL Server e speravo che alcuni guru del database potessero offrire alcune indicazioni sulle migliori pratiche.
Solo per dare un po 'di background, il mio team si è recentemente ristretto a 2 persone e ci siamo appena uniti con un altro team di 6 persone. Il mio team aveva impostato un ambiente SQL Server eseguendo il backup di un desktop su un altro desktop (e di notte verso la rete), mentre il nuovo team ha un ambiente SQL Server formale, eseguito su un server dedicato, con backup e manutenzione gestiti da un team dedicato Finora sono buone notizie per il mio team.
Ora alla query. Il mio team ha progettato tutte le nostre tabelle per appartenere a un nome schema di 3 lettere (ad esempio Utente = USR, Generale = GEN, Conto = ACC) che in linea generale si riferiscono a specifiche applicazioni, anche se vi sono molte sovrapposizioni. Il mio nuovo team proviene da un background di Access e ha implementato le loro tabelle all'interno di dbo con un perfix di 3 lettere seguito da "_tbl", quindi gli esempi precedenti sarebbero dbo.USR_tblTableName, dbo.GEN_tblTableName e dbo.ACC_tblTableName.
Inoltre, né il mio vecchio team né il mio nuovo team sono andati a vivere con i loro SQL Server (siamo entrambi casualmente migrati dagli ambienti Access) e il nuovo team ha detto che è disposto a prendere in considerazione l'adozione del nostro approccio se possiamo spiegare come ciò sarebbe vantaggioso.
Non stiamo anticipando le autorizzazioni della tabella di gestione a livello di schema, poiché utilizzeremo login a livello di applicazione ei prefissi di 7 caratteri non sono un problema poiché stiamo usando LINQ in modo che le tabelle possano semplicemente essere rinominate in DMBL ( anche se so che presenta alcune sfide quando aggiorniamo il DBML).
Quindi, dato che entrambe le squadre devono essere allineate l'una con l'altra, qualcuno può offrire argomenti convincenti in ogni caso?