sql-server-2005 - tabla - obtener esquema de base de datos sql server
¿De qué sirven los esquemas de SQL Server? (11)
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 acabo de usar 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 Schemes, ¿qué no puedes hacer con los propietarios y los roles? ¿Cuáles son sus beneficios específicos?
Al igual que Namespace of C # codes.
Creo que los esquemas son como muchas características nuevas (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 inclino 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 utilizarlo casualmente para obtener beneficios a corto plazo; y una vez que está allí, puede convertirse en kudzu.
En SQL Server 2000, los objetos creados se vincularon a ese usuario en particular, como si un usuario, por ejemplo, Sam creara un objeto, digamos, Empleados, esa tabla aparecería como: Sam.Employees. ¿Qué pasa si Sam deja la compnay se muda a otra área comercial? Tan pronto como elimines 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 todos sus objetos dentro de un esquema como Emp_Schema. Ahora, si crea un objeto Empleados dentro de Emp_Schema, el objeto se denominará Emp_Schema.Employees. Incluso si la cuenta de usuario Sam necesita ser eliminada, el esquema no se vería afectado.
En una tienda 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.
No veo el beneficio en aliasing a los usuarios vinculados a Schemas. Aquí está el porqué ...
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, en cualquier forma, esa cuenta tiene un alias para la cuenta de usuario "dbo" o tiene una cuenta completa 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 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 descartar esquemas y roles, y simplemente permitirle agrupar grupos en cualquier combinación que desee, luego, en cada nivel, indicar al sistema si los permisos se heredan, denegan o sobrescriben de manera personalizada. unos. 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.
Sé que es un hilo antiguo, pero solo miré en los esquemas y creo que lo siguiente podría ser otro buen candidato para el uso del esquema:
En un Datawarehouse, con datos procedentes de diferentes fuentes, puede usar un esquema diferente para cada fuente y, por ejemplo, controlar el acceso según los esquemas. También evita las posibles colisiones de nombres entre las distintas fuentes, ya que otro cartel respondió anteriormente.
Si mantiene discreto el esquema, puede escalar una aplicación mediante la implementación de 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.
También pueden proporcionar un tipo de protección de colisión de nombres para los datos del complemento. 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.
Tiendo a estar de acuerdo con Brent en este ... mira 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. Hace cosas desordenadas No los uses si puedes evitarlo. Y trate de obedecer la regla K (eep) I (t) S (implementar) S (tupida).
desarrollo: cada uno de nuestros desarrolladores obtiene su propio esquema como un sandbox para jugar.
Los esquemas lógicamente agrupan tablas, procedimientos y vistas juntos. Todos los objetos relacionados con los employee en el esquema de 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.