¿De qué sirven los esquemas SQL Server?

Al igual que el Espacio de nombres de los códigos C#.

También pueden proporcionar una especie de protección de colisión de nombres para los datos del complemento. Por ejemplo, la nueva función de Captura de datos de cambio de SQL Server 2008 coloca las tablas que utiliza en un esquema cdc independiente. De esta manera, no tienen que preocuparse por un conflicto de nombres entre una tabla de CDC y una tabla real utilizada en la base de datos, y para el caso pueden sombrear deliberadamente los nombres de las tablas reales.

Sé que es un hilo viejo, pero acabo de mirar los esquemas yo mismo y creo que lo siguiente podría ser otro buen candidato para el uso de esquemas:

En un Datawarehouse, con datos procedentes de diferentes fuentes, puede utilizar un esquema diferente para cada fuente y, a continuación, por ejemplo, controlar el acceso en función de los esquemas. También evita las posibles colisiones de nombres entre las diversas fuentes, como otro póster respondió arriba.

Si mantiene su esquema discreto, puede escalar una aplicación implementando un esquema determinado en un nuevo servidor de BD. (Esto supone que tiene una aplicación o sistema que es lo suficientemente grande como para tener una funcionalidad distinta).

Un ejemplo, considere un sistema que realiza registros. Todas las tablas de registro y SPs están en el esquema [logging]. El registro es un buen ejemplo porque es raro (si es que alguna vez) que otras funcionalidades del sistema se superpongan (es decir, se unan a) objetos en el registro esquema.

Una sugerencia para usar esta técnica have tenga una cadena de conexión diferente para cada esquema en su aplicación / sistema. A continuación, implemente los elementos de esquema en un nuevo servidor y cambie la cadena de conexión cuando necesite escalar.

Tiendo a estar de acuerdo con Brent en este caso... vea esta discusión aquí. http://www.brentozar.com/archive/2010/05/why-use-schemas /

En resumen... los esquemas no son muy útiles excepto para casos de uso muy específicos. Hace las cosas desordenadas. No los use si puede evitarlo. Y tratar de obedecer la regla K(eep) I(t) S(imple) S (tupid).

No veo el beneficio en aliasing a los usuarios vinculados a Esquemas. He aquí por qué....

La mayoría de las personas conectan sus cuentas de usuario a bases de datos a través de roles inicialmente, tan pronto como se asigna un usuario al administrador del sistema, o al rol de base de datos db_owner, en cualquier forma, esa cuenta o bien se asocia a la cuenta de usuario "dbo", o tiene permisos completos en una base de datos. Una vez que esto ocurra, no importa cómo se asigne a un esquema más allá de su esquema predeterminado (que tiene el mismo nombre que su usuario cuenta), esos derechos de dbo se asignan a los objetos que cree bajo su usuario y esquema. No tiene sentido.....y solo un espacio de nombres y confunde la verdadera propiedad de esos objetos. Su diseño es pobre si me preguntas....quienquiera que lo haya diseñado.

Lo que deberían haber hecho es crear "Grupos", y desechar esquemas y roles y solo permitirle grupos de grupos de nivel en cualquier combinación que desee, luego en cada nivel decirle al sistema si los permisos se heredan, se niegan o se sobrescriben con los personalizados. Esto habría sido mucho más intuitivo y permitió a los DBA controlar mejor quiénes son los propietarios reales de esos objetos. En este momento, en la mayoría de los casos, el usuario predeterminado de dbo SQL Server tiene esos derechos....no el usuario.

En una tienda de ORACLE en la que trabajé durante muchos años, se utilizaron esquemas para encapsular procedimientos (y paquetes) que se aplicaban a diferentes aplicaciones front-end. Un esquema ' API ' diferente para cada aplicación a menudo tenía sentido, ya que los casos de uso, los usuarios y los requisitos del sistema eran bastante diferentes. Por ejemplo, un esquema ' API ' era para una aplicación de desarrollo / configuración solo para ser utilizado por los desarrolladores. Otro esquema ' API ' era para acceder a los datos del cliente a través de vistas y procedimientos (búsquedas). Otro esquema ' API ' encapsulaba código que se usaba para sincronizar el desarrollo/configuración y los datos del cliente con una aplicación que tenía su propia base de datos. Algunos de estos esquemas "API", bajo las cubiertas, todavía compartirían procedimientos y funciones comunes entre sí (a través de otros esquemas "COMUNES") donde tenía sentido.

Diré que no tener un esquema probablemente no es el fin del mundo, aunque puede ser muy útil. Realmente, es la falta de paquetes en SQL Server que realmente crea problemas en mi mente... pero ese es un tema diferente.

Creo que los esquemas son como muchas características nuevas (ya sea para SQL Server o cualquier otra herramienta de software). Debe evaluar cuidadosamente si el beneficio de agregarlo a su kit de desarrollo compensa la pérdida de simplicidad en el diseño y la implementación.

Me parece que los esquemas son aproximadamente equivalentes a los espacios de nombres opcionales. Si se encuentra en una situación en la que los nombres de los objetos chocan y la granularidad de los permisos no es lo suficientemente fina, aquí hay una herramienta. (Me inclino a decir que hay podrían ser cuestiones de diseño que deben abordarse en un nivel más fundamental en primer lugar.)

El problema puede ser que, si está allí, algunos desarrolladores comenzarán a usarlo casualmente para beneficio a corto plazo; y una vez que esté allí, puede convertirse en kudzu.

En SQL Server 2000, los objetos creados estaban vinculados a ese usuario en particular, como si un usuario Sam crea un objeto, por ejemplo, Empleados, que la tabla aparecería como: Sam.Empleado. Lo acerca de si Sam está dejando la empresa o se muda a otra área de negocios. En cuanto elimines el usuario Sam, lo que le pasaría a Sam.Tabla de empleados? Probablemente, tendrías que cambiar la propiedad primero de Sam.Empleados a dbo.Empleada. Schema proporciona una solución para superar este problema. Sam puede cree todo su objeto dentro de un schemam como Emp_Schema. Ahora, si crea un objeto Empleados dentro de Emp_Schema entonces el objeto sería se refiere a como Emp_Schema.Empleado. Incluso si la cuenta de usuario Sam necesita ser eliminada, el el esquema no se vería afectado.

Desarrollo - cada uno de nuestros desarrolladores obtiene su propio esquema como una caja de arena para jugar.