¿De qué sirven los esquemas de SQL Server?


185

No soy principiante en el uso de bases de datos SQL, y en particular SQL Server. Sin embargo, he sido principalmente un chico de 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é asignaría alguno de los esquemas integrados?

EDITAR: Para aclarar, creo que estoy buscando los beneficios de los esquemas. Si solo lo va a usar como un esquema de seguridad, parece que los roles de la base de datos ya ocuparon ese ... er ... 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.).

Supongo que lo que quiero decir es, ¿qué hacen los esquemas que no podrías hacer con los propietarios y los roles? ¿Cuáles son sus beneficios específicos?

Respuestas:


164

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

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


21
La posibilidad de asignar permisos a un esquema hace que valga la pena desde una perspectiva de administración.
Hakan Winther

9
¿No podrías usar una base de datos separada?
Sam yi

77
Este permiso de esquema suena bien en papel ... pero rara vez se usa correctamente. Para mí no vale la pena.
Sam yi

3
Pero si ese es el caso, ¿no podría lograr lo mismo usando convenciones de nomenclatura? No estoy sugiriendo que NO haya un caso de uso para ello; es, la mayoría de las veces, una suma por sustracción.
Sam yi

66
@ Ajedi32, sí ... con los esquemas puede obtener una única confirmación atómica en un único registro de transacciones y respaldar todos sus datos de una sola vez en lugar de tener dos bases de datos que no están sincronizadas, así como combatir las transacciones distribuidas.
Matthew Whited

31

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


16
Sin embargo, desafortunadamente , los esquemas y los espacios de nombres .NET no funcionan muy bien juntos desde una perspectiva ORM ( es decir, Entity Framework ). Las tablas en el MyDatabase.MySchemaesquema no se asignan mágicamente a clases de entidad en el MyProject.MyDatabase.MySchemaespacio de nombres. También vale la pena señalar que cualquier .hack de notación de punto ( ) en los nombres de la tabla terminará como subrayado ( _) en los nombres de clase. Solo comida para un pensamiento desafortunado.
Dan Lugg

2
Buena analogía para la enseñanza. No veo que se tome al 100% literalmente ... (esas advertencias suenan menores en la práctica)
Samantha Branham

66
Personalmente, desearía que fueran más como espacios de nombres .NET, de modo que uno pudiera anidar un número arbitrario de esquemas ( como puede hacerlo con espacios de nombres ) para fines organizativos. Eso, y desearía que pudieran mapear mejor en EF.
Dan Lugg

Son no como espacios de nombres en cualquier idioma que se me ocurre.
Tanveer Badar

29

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


17

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

En un Datawarehouse, con datos provenientes de diferentes fuentes, puede usar un esquema diferente para cada fuente y luego, por ejemplo, controlar el acceso en función de los esquemas. También evita las posibles colisiones de nombres entre las diversas fuentes, ya que otro póster respondió anteriormente.


9

Si mantiene su esquema discreto, puede escalar una aplicación implementando un esquema dado en un nuevo servidor de base 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 [registro]. El registro es un buen ejemplo porque es raro (si alguna vez) que otra funcionalidad en el sistema se superponga (es decir, unirse 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, despliega los elementos del esquema en un nuevo servidor y cambia la cadena de conexión cuando necesita escalar.


8

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

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


2
No creo que Brent esté argumentando que "los esquemas son malos", solo que usar esquemas no predeterminados es mucho más complejo que simplemente usar el esquema predeterminado. El resto de su resumen es exacto.
Joseph Daigle

"Si [los esquemas se usan] correctamente, te permiten segregar los permisos por grupos de objetos". ~ brentozar.com/archive/2010/05/why-use-schemas
LL Learner

7

No veo el beneficio de aliasar usuarios vinculados a esquemas. Aquí es por qué ...

La mayoría de las personas conectan sus cuentas de usuario a bases de datos mediante roles inicialmente. Tan pronto como asigna un usuario al administrador del sistema o al rol de base de datos db_owner, de cualquier forma, esa cuenta tiene un alias a la cuenta de usuario "dbo", o tiene permisos 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 de dbo se asignan a los 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 de grupos en cualquier combinación que desee, luego, en cada nivel, decirle al sistema si los permisos se heredan, se niegan o se sobrescriben con personalización unos. Esto habría sido mucho más intuitivo y habría permitido a los DBA 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 predeterminado de SQL Server de dbo tiene esos derechos ... no el usuario.


7

En una tienda 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 de '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 que solo utilizarían los desarrolladores. Otro esquema '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 'API', bajo las cubiertas, aún compartirían procedimientos y funciones comunes entre sí (a través de otro 'COMÚN'

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.


Con Oracle, dado que 1 instancia = 1 base de datos = 1 licencia para pagar, las personas usan shemas para evitar crear otra base de datos y pagar otra licencia. En SQl Server, 1 servidor puede manejar muchas bases de datos.
Patrick Honorez

5

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 más o menos equivalentes a espacios de nombres opcionales. Si se encuentra en una situación en la que los nombres de los objetos están colisionando y la granularidad de los permisos no es lo suficientemente buena, 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 para beneficio a corto plazo; y una vez allí, puede convertirse en kudzu.


3

En SQL Server 2000, los objetos creados estaban vinculados a ese usuario en particular, como si un usuario, por ejemplo, Sam crea un objeto, por ejemplo, Empleados, esa tabla aparecería como: Sam.Employees. ¿Qué pasa si Sam deja la compañía o se muda a otra área de negocios? Tan pronto como elimine al usuario Sam, ¿qué pasaría con la tabla Sam.Employees? Probablemente, primero tendría que cambiar la propiedad de Sam.Employees a dbo.Employess. Schema proporciona una solución para superar este problema. Sam puede crear todo su objeto dentro de un esquema como Emp_Schema. Ahora, si crea un objeto Empleados dentro de Emp_Schema, entonces el objeto se denominará Emp_Schema.Employees. Incluso si la cuenta de usuario Sam necesita ser eliminada, el esquema no se vería afectado.


1
Esto ya no es cierto ya que ha habido dos nuevas versiones desde 2000
Hogan

0

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


29
-1 Es mejor dar a los desarrolladores copias enteras separadas de la base de datos para jugar en su propia máquina. De lo contrario, solo podrían cambiar con seguridad lo que está dentro de su esquema. Complica la promoción de la vida y también complica la separación del esquema por otros motivos descritos por otras respuestas.
Stephen Turner

55
No puedo hablar por la aplicación en la que está trabajando ... pero su desarrollo debería reflejar la producción tanto como sea posible. Tener esquemas en dev y no en prod puede ser problemático.
sam yi

0

Aquí un buen ejemplo de implementación del uso de esquemas con SQL Server. Teníamos varias aplicaciones de acceso ms. Queríamos convertirlos a un portal de aplicaciones ASP.NET. Cada aplicación de ms-access está escrita como una aplicación para ese portal. Cada aplicación ms-access tiene sus propias tablas de base de datos. Algunos de ellos están relacionados, los colocamos en el esquema dbo común de SQL Server. El resto tiene sus propios esquemas. De esa manera, si queremos saber qué tablas pertenecen a una aplicación en el portal de aplicaciones ASP.NET que se pueden navegar, visualizar y mantener fácilmente.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.