Utilizzo dello schema del database

4

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?

    
posta CrazyHorse 03.12.2012 - 14:51
fonte

1 risposta

6

Questo è lontano da una risposta autorevole sull'uso degli schemi, ma in generale si desidera utilizzarli per uno dei seguenti motivi: Sicurezza isolamento o portabilità di oggetti correlati.

Sicurezza

È possibile assegnare autorizzazioni di sicurezza basate sullo schema, che semplifica enormemente le strutture complicate. Pensa a un sistema di gestione delle risorse umane in cui alcune persone hanno bisogno di vedere ore, i manager hanno bisogno di vedere i file, ma solo le persone specifiche devono vedere tutto ciò che riguarda il pagamento. Se metti lo schema di pagamento in uno schema Salary , puoi isolare abbastanza efficacemente dal resto dei dati.

Questo può essere fatto separatamente con altri metodi come le viste o concedere le autorizzazioni a oggetti specifici, ma se vuoi separare un gruppo di oggetti correlati questa è una strada facile da percorrere.

Portabilità

Alcuni credono che gli schemi rendano gli oggetti più portabili. Continuando con il nostro esempio precedente, se hai bisogno di mettere i dati di Salary e gli oggetti correlati in un altro database o su un altro server, se sono interamente contenuti in quello schema sarebbe (potenzialmente) meno lavoro per spostarli tutti da quando hai copiato tutti gli oggetti in quello schema.

In pratica, se ti attieni a una convenzione sui nomi, puoi ottenere lo stesso effetto senza usare uno schema.

Quindi, se non hai problemi di sicurezza con questi oggetti, e non pensi che avrai mai bisogno di spostarli (e userai una convenzione di denominazione severa ANYWAYS), allora è davvero un problema come a cui sarebbe preferito.

    
risposta data 03.12.2012 - 15:56
fonte

Leggi altre domande sui tag