Criterios de decisión sobre cuándo utilizar un esquema no dbo frente a una nueva base de datos

Soy principalmente un desarrollador de aplicaciones, pero tengo que hacer todo el trabajo inicial de la base de datos para mi proyecto actual (por cierto ... es MS SQL Server 2008 ). Como primera decisión, estoy tratando de averiguar si dividir mi estado usando bases de datos separadas o usando esquemas separados en la misma base de datos. He leído un poco sobre los esquemas de SQL Server y parece una forma natural de separar dominios de objetos (lo que me gusta ), pero no estoy seguro de si puede haber costos ocultos para este patrón.

¿Cuáles son las cosas más prácticas que debo considerar al seleccionar entre estos dos enfoques? Si evito el dbo.mytablefavor myschema.mytable, ¿crearé otros desafíos ( o problemas ) para mi arquitectura?

Como nota al margen ... En algún momento, esto será entregado a un DBA real para mantener / apoyar, así que estoy tratando de asegurarme de no hacerles la vida más difícil.

Comenzaré diciendo que no considere los esquemas como espacios de nombres o dominios de objeto en el sentido OO. Los esquemas son esencialmente contenedores de permisos con algún valor agregado (ver más abajo)

Además, "esquemas separados" o "bases de datos separadas" son 2 conceptos diferentes. Los datos que deben ser transaccional y referencialmente coherentes deben estar en la misma base de datos. Ver una base de datos o diez? Artículo de blog para más.

En esa base de datos, puede o no usar esquemas para organizar sus objetos.

Personalmente, soy fanático de los esquemas y siempre los uso, pero para cosas como permisos y agrupación lógica. Para eso, lo remitiré a las preguntas anteriores donde puede ver que la opinión general está a favor de ellas:

• Diseño de esquemas: ¿mejores prácticas?
• ¿Qué estándar debo seguir al nombrar tablas y vistas?
• ¿Uso excesivo / uso correcto de esquemas?

Para el caso de bases de datos separadas, vea la respuesta de Aaron , pero todo esto depende del requisito de "coherencia transaccional y referencial".

De acuerdo con @gbn. Diseñé soluciones usando esquemas para separación y bases de datos para separación, y creo que usar bases de datos es mucho más práctico. Un par de razones:

1. Hacer que su aplicación se conecte a una base de datos específica del contexto y luego ejecutar las mismas consultas es mucho más fácil que hacer que sus consultas se inyecten <schema>frente a todas las referencias de objetos. Esto se presta a una gran cantidad de SQL dinámico, a muchos inicios de sesión de aplicaciones diferentes con esquemas predeterminados (lo que significa que su código no usaría el prefijo de esquema, confiando en el esquema predeterminado del usuario de la aplicación, puede conducir a una acumulación masiva de caché del plan y una depuración difícil), o una gran cantidad de procedimientos almacenados para administrar (imagine solo un informe simple, si necesita uno por esquema, entonces el código cambia, ahora tiene que cambiar el mismo código varias veces, una vez para cada esquema).
2. La separación por base de datos le permite la flexibilidad de mover bases de datos ocupadas a instancias / almacenamiento más rápidos o diferentes sin tener que extraer objetos de una gran base de datos que lo abarca todo. La mayoría de la gente no lo piensa con tanta antelación, pero definitivamente es un problema de escala potencial. Especialmente si termina teniendo un esquema que "se hace cargo" y requiere la mayoría de los recursos en el servidor, dividirlos puede ser una tarea extremadamente engorrosa, incluso si ya están separados por un esquema.
3. Las bases de datos separadas también pueden permitirle tener diferentes horarios de mantenimiento y copias de seguridad para cada división. No estoy seguro de lo que quiere decir con "dividir por estado", pero suponiendo que quiere decir aislar a los clientes, puede tener clientes con diferentes requisitos y diferentes tolerancias para la pérdida de datos, el mantenimiento del índice, etc.
4. Puede terminar con clientes que, por ley o por política corporativa, necesitan que mantenga sus datos separados de cualquier otra persona. Esto generalmente es aceptable en el nivel de la base de datos, pero el nivel del esquema generalmente será insuficiente. Es posible que no tenga estos clientes ahora, pero podría convertirse en un verdadero problema más adelante si lo tiene.