Criteri di decisione su quando utilizzare uno schema non dbo rispetto a un nuovo database

Sono principalmente uno sviluppatore di applicazioni ma mi ritrovo a dover fare tutto il lavoro di database iniziale per il mio progetto attuale ( tra cui ... il suo MS SQL Server 2008 ). Come prima decisione, sto cercando di capire se dividere il mio stato usando database separati o usando schemi separati nello stesso database. Ho fatto una piccola lettura sugli schemi di SQL Server e sembra un modo naturale di separare domini di oggetti ( che mi piacciono ), ma non sono sicuro che ci possano essere costi nascosti per questo modello.

Quali sono le cose più pratiche che dovrei considerare quando seleziono tra questi due approcci? Se evito il dbo.mytablefavore myschema.mytable, creerò altre sfide ( o problemi ) per la mia architettura?

Come nota a margine ... Ad un certo punto questo verrà consegnato a un vero DBA per mantenere / supportare, quindi sto cercando di assicurarmi di non rendere le loro vite più difficili.

Inizierò dicendo che non considerare gli schemi come spazi dei nomi o domini di oggetti in senso OO. Gli schemi sono essenzialmente contenitori di autorizzazioni con un certo valore aggiunto (vedi sotto)

Inoltre, "schemi separati" o "database separati" sono 2 concetti diversi. I dati che devono essere coerenti dal punto di vista transazionale e referenziale devono trovarsi nello stesso database. Vedi un database o dieci? articolo blog per di più.

In quel database, puoi o meno usare schemi per organizzare i tuoi oggetti.

Personalmente, sono un fan degli schemi e li uso sempre ma per cose come permessi e raggruppamenti logici. Per questo, ti rimando alle domande precedenti in cui puoi vedere l'opinione generale è a loro favore:

• Progettazione dello schema: migliori pratiche?
• Quale standard devo seguire quando nomina nomi di tabelle e viste?
• Uso eccessivo / uso corretto degli schemi?

Per il caso di database separati, vedere la risposta di Aaron , ma tutto ciò dipende dal requisito "coerente dal punto di vista transazionale e referenziale".

Accetto con @gbn. Ho progettato soluzioni usando schemi per separazione e database per separazione, e trovo che usare database sia molto più pratico. Un paio di motivi:

1. Avere la tua app connessa a un database specifico del contesto e quindi eseguire le stesse query è molto più semplice che far iniettare le tue query <schema>davanti a tutti i riferimenti agli oggetti. Questo si presta a un sacco di SQL dinamico, molti accessi alle applicazioni diversi con schemi predefiniti (il che significa che il codice non userebbe il prefisso dello schema, basandosi sullo schema predefinito dell'utente dell'applicazione - può portare a un enorme gonfiore della cache del piano e un difficile debug), o molte procedure memorizzate da gestire (immagina solo un semplice report, se ne hai bisogno per schema, quindi il codice cambia, ora devi cambiare lo stesso codice più volte, una volta per ogni schema).
2. La separazione per database offre la flessibilità di spostare database occupati in archivi / istanze più veloci o diversi senza dover estrarre oggetti da un grande database onnicomprensivo. La maggior parte delle persone non ci pensa con largo anticipo, ma è sicuramente un potenziale problema di scala. Soprattutto se si finisce per avere uno schema che "prende il sopravvento" e richiede la maggior parte delle risorse sul server, dividerle può essere un'attività estremamente ingombrante, anche se sono già separate dallo schema.
3. Database separati possono anche consentire di avere piani di manutenzione e backup diversi per ogni divisione. Non sono sicuro di cosa intendi per "divisione per stato", ma supponendo che intendi isolare i clienti, potresti avere clienti con requisiti diversi e tolleranza diversa per la perdita di dati, la manutenzione dell'indice, ecc.
4. Potresti ritrovarti con clienti che, per legge o per politica aziendale, hanno bisogno che tu mantenga i loro dati separati da chiunque altro. Questo è generalmente accettabile a livello di database, ma a livello di schema sarà generalmente insufficiente. Al momento potresti non avere questi clienti, ma in caso contrario potresti diventare un vero problema.