¿De qué sirven los esquemas de SQL Server?

Question

No soy un principiante en el uso de bases de datos SQL, y en particular SQL Server. Sin embargo, he sido principalmente un tipo SQL 2000 y siempre me han confundido los esquemas en 2005+. Sí, conozco la definición básica de un esquema, pero ¿para qué se usan realmente en una implementación típica de SQL Server?

Siempre he usado el esquema predeterminado. ¿Por qué querría crear esquemas especializados? ¿Por qué debería asignar cualquiera de los esquemas integrados?

EDITAR: Para aclarar, creo que estoy buscando los beneficios de los esquemas. Si solo va a utilizarlo como un esquema de seguridad, parece que las funciones de la base de datos ya tienen ese ... eh ... um ... rol. Y usarlo como un especificador de espacio de nombres parece haber sido algo que podría haber hecho con la propiedad (dbo versus usuario, etc.).

Creo que a lo que me refiero es a qué hacen los esquemas que no se puede hacer con los propietarios y los roles. ¿Cuáles son sus beneficios específicos?

Answer 1

Los esquemas lógicamente agrupan tablas, procedimientos, vistas juntas. Todos los objetos relacionados con los empleados en el esquema employee, etc.

También puede otorgar permisos a un solo esquema, de modo que los usuarios solo puedan ver el esquema al que tienen acceso y nada más.

Answer 2

desarrollo - cada uno de nuestros desarrolladores obtener su propio esquema como una caja de arena para jugar en

Answer 3

También pueden proporcionar una especie de protección contra colisiones de nombres para los datos del plugin.. Por ejemplo, la nueva característica Cambiar captura de datos en SQL Server 2008 coloca las tablas que usa en un esquema de cdc separado. De esta forma, no tienen que preocuparse por un conflicto de nombres entre una tabla CDC y una tabla real utilizada en la base de datos, y para ese asunto, pueden ocultar deliberadamente los nombres de las tablas reales.

Answer 4

Creo que los esquemas son como muchas nuevas características (ya sea 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 más o menos equivalentes a los espacios de nombres opcionales. Si se encuentra en una situación donde los nombres de los objetos están colisionando y la granularidad de los permisos no es lo suficientemente fina, aquí hay una herramienta. (Me inclinaría a decir que podría haber problemas de diseño que deberían abordarse en un nivel más fundamental primero.)

El problema puede ser que, si está allí, algunos desarrolladores comenzarán a usarlo casualmente de manera casual- beneficio a término; y una vez que está allí, puede convertirse en kudzu.

Answer 5

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

Answer 6

Sé que es un viejo hilo, pero yo sólo miraba en los esquemas de mí mismo y creo que el siguiente podría ser otro buen candidato para el uso del esquema:

En un Datawarehouse, con los datos procedentes de distintas fuentes, se puede utilizar una esquema diferente para cada fuente, y luego, por ejemplo controlar el acceso basado en los esquemas. También evita las posibles colisiones de nombres entre las distintas fuentes, ya que otro cartel respondió anteriormente.

Answer 7

En SQL Server 2000, los objetos creados estaban vinculados a ese usuario en particular, al igual que si un usuario, por ejemplo Sam crea un objeto, por ejemplo, los empleados, la mesa aparecería como: Sam.Employees. ¿Qué acerca de si Sam está dejando la compnay o se mueve a tan otra área comercial. Tan pronto como elimine el usuario Sam, ¿qué pasaría con la tabla Sam.Employees?Probablemente, tendría que cambiar primero la propiedad de Sam.Employees a dbo.Employess. Schema proporciona una solución para superar este problema. Sam puede crear todos sus objetos dentro de un esquema como Emp_Schema. Ahora, si crea un objeto Empleados dentro de Emp_Schema, entonces el objeto sería conocido como Emp_Schema.Employees. Incluso si la cuenta de usuario Sam necesita ser eliminada, el esquema no se vería afectado.

Answer 8

Si mantiene su esquema discreto, puede escalar una aplicación implementando un esquema dado en un nuevo servidor de bases de datos. (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 el registro. Todas las tablas de registro y SP están en el esquema [logging]. El registro es un buen ejemplo porque es raro (si es que alguna vez) que otras funciones en el sistema se superpongan (es decir, que se unan) a objetos en el esquema de registro.

Una sugerencia para usar esta técnica: tenga una cadena de conexión diferente para cada esquema en su aplicación/sistema. Luego implementa los elementos de esquema en un nuevo servidor y cambia la cadena de conexión cuando necesita escalar.

Answer 9

No veo el beneficio en aliasing de los usuarios vinculados a Schemas. 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 asigna un usuario a sysadmin, o al rol de base de datos db_owner, de cualquier forma, esa cuenta es un alias a la cuenta de usuario "dbo", o tiene permisos completos en una base de datos. Una vez que eso ocurre, no importa cómo se asigne a un esquema más allá de su esquema predeterminado (que tiene el mismo nombre que su cuenta de usuario), esos derechos dbo se asignan a esos objetos que crea bajo su usuario y esquema. Es un poco inútil ... y solo un espacio de nombres y confunde la verdadera propiedad de esos objetos. Su diseño pobre si me preguntas .... quien lo diseñó.

Lo que deberían haber hecho es crear "Grupos", y arrojar esquemas y roles y simplemente permitirle agrupar grupos en la combinación que desee, luego en cada nivel decirle al sistema si los permisos son heredados, denegados, o sobrescrito con los personalizados. Esto hubiera sido mucho más intuitivo y permitió a los administradores de bases de datos controlar mejor quiénes son los verdaderos propietarios de esos objetos. En este momento está implícito en la mayoría de los casos que el usuario dbo predeterminado de SQL Server tiene esos derechos ... no el usuario.

Answer 10

En una tienda de ORACLE en la que trabajé durante muchos años, los esquemas se usaban para encapsular procedimientos (y paquetes) que se aplicaban a diferentes aplicaciones de front-end. Un esquema diferente de 'API' 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 de 'API' era para una aplicación de desarrollo/configuración que los desarrolladores usarían solo. Otro esquema de 'API' era para acceder a los datos del cliente a través de vistas y procedimientos (búsquedas). Otro código encapsulado de esquema 'API' que se utilizó 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 de 'API', bajo las carátulas, aún compartirían procedimientos y funciones comunes entre sí (a través de otros esquemas 'COMUNES') donde tuviera sentido.

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

Answer 11

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

En resumen ... los esquemas no son muy útiles, excepto en casos de uso muy específicos. Haz las cosas desordenadas. No los uses si puedes evitarlo.Y trate de obedecer la regla K (eep) I (t) S (implementar) S (tupida).