Desventajas de "CON ESQUEMA DE ESQUEMA" en SQL Server?

Question

Tengo una base de datos con cientos de tablas nombradas torpemente (CG001T, GH066L, etc.), y tengo vistas de cada una con su nombre "amigable" (la vista "CLIENTES" es "SELECCIONAR * DESDE GG120T", para ejemplo). Deseo agregar "CON ESQUEMA DE ESCRIBIR" a mis vistas para que pueda tener algunas de las ventajas asociadas, como poder indexar la vista, ya que un puñado de vistas ha calculado columnas que son costosas de calcular sobre la marcha.

¿Hay aspectos negativos para SCHEMABINDING estas vistas? He encontrado algunos artículos que aluden vagamente a los inconvenientes, pero nunca los analizo en detalle. Sé que una vez que una vista está en esquema, no se puede alterar nada que pueda afectar la vista (por ejemplo, un tipo de datos de columna o intercalación) sin soltar primero la vista, así que esa es una, ¿pero aparte de eso? Parece que la capacidad de indexar la vista en sí misma superaría por mucho la desventaja de planificar las modificaciones de su esquema con más cuidado.

Answer 1

Ninguna en absoluto. Es más seguro. lo usamos en todas partes.

Answer 2

No podrá alterar/soltar la tabla, a menos que primero suelte la vista.

Answer 3

Si estas tablas son de una aplicación de terceros (son notorias por tratar de ocultar sus tablas), causa y actualiza a fallar si intenta alterar cualquiera de estas tablas.

Solo tiene que modificar las vistas sin el esquema antes de la actualización/actualización y luego volver a colocarlas. Como otros han mencionado. Solo requiere planificación, disciplina, etc.

Answer 4

Un inconveniente es que si enlaza una vista en esquema, solo puede hacer referencia a otras vistas con esquema.

Lo sé porque traté de enlazar una vista y me encontré con un mensaje de error que me indicaba que no se podía enlazar con el esquema porque una de las otras vistas a las que hace referencia tampoco tiene esquemas.

La única consecuencia de esto es que si de repente desea actualizar una vista en esquema para hacer referencia a una vista nueva o existente, es posible que tenga que enlazar esquemáticamente esa vista nueva o existente. En ese caso, no podrá actualizar la vista, y es mejor que los desarrolladores de la base de datos sepan cómo trabajar con vistas en esquema.

Answer 5

Oh, hay desventajas DEFINITIVAMENTE a usar SCHEMABINDING - éstos vienen de hecho de la SCHEMABINDING, especialmente cuando se combina con las columnas calculadas "bloquea" el RELACIONES y hace algunos cambios "triviales" rematadamente casi imposible.

1. Crear una tabla.
2. Cree un UDF SCHEMABOUND.
3. Cree una columna COMPUTED PERSISTED que haga referencia a la UDF.
4. Agregue un ÍNDICE sobre dicha columna.
5. Intente actualizar la UDF.

¡Buena suerte con eso!

1. La UDF no se puede quitar o modificar porque es SCHEMABOUND.
2. La COLUMNA no se puede quitar porque se utiliza en un ÍNDICE.
3. La COLUMNA no se puede modificar porque está COMPUTADA.

Bueno, frak. De Verdad..!?! Mi día acaba de convertirse en un PITA. (Ahora, herramientas como ApexSQL Dif puede manejar esto cuando se les proporciona un esquema modificado, pero el problema aquí es que no puedo incluso modificar el esquema para empezar!)

No estoy en contra SCHEMABINDING, la mente (y es necesario para una UDF en este caso), pero Estoy en contra de que no haya una forma (que pueda encontrar) de "desactivar temporalmente" el SCHEMABINDING.

Answer 6

Otra desventaja es que necesita utilizar nombres calificados de esquema para todo: Usted obtendrá una carga de mensajes de error como este:

No se puede esquema de vista bind 'vista' porque el nombre 'mesa' no es válido para enlace de esquema. Los nombres deben estar en formato de dos partes y un objeto no puede referirse a .

También para 'desactivar' el enlazado de esquemas usted altera la vista que requiere que redefina la instrucción de selección de la vista. Creo que lo único que no tienes que redefinir es ninguna subvención. Esto me saca de quicio ya que sobrescribir la vista parece una operación intrínsecamente insegura.

Es un poco como la manera en que agregar restricciones no nulos te obliga a sobreescribir el tipo de datos de la columna: desagradable.

También deberá redefinir cualquier otra vista o procedimiento que dependa del objeto enlazado al esquema que desee cambiar ... esto significa que deberá redefinir (y posiblemente romper) una gran cascada de funciones y vistas solo para agregar (por ejemplo) una restricción no nula a una columna.

personalmente creo que ésto no representan realmente una solución y su mejor tener un proceso mediante el cual decente que se aplique cualquier base de datos cambia automáticamente de modo que tampoco un pesadilla para cambiar la base de datos. De esta forma, puede hacer que todas sus vistas + funciones se descarten y vuelvan a crearse desde cero (de todos modos se verifican en la creación) como parte del proceso cuando se aplican cambios a las tablas.

Answer 7

esto parece una desventaja de mí (# 's son mías):

Cannot create index on view "###.dbo.###" because it uses a LEFT, RIGHT, or FULL OUTER join, and no OUTER joins are allowed in indexed views. Consider using an INNER join instead. 

La clase I necesitan mi izquierda se une. This SO question es relevante.

Answer 8

Al utilizar el Marco de prueba de unidades tSQLt, encontrará problemas y necesitará soluciones cuando utilice el método FakeTable, que no le permitirá falsificar una tabla vinculada a una vista con esquema.

Answer 9

Los negativos mencionados apenas superan esta buena práctica desde SQL Svr 2005. Evita la cola de la tabla temida. Una gran desventaja para mí es que los sprocs, funcs, views vinculados al esquema no pueden incluir bases de datos "extranjeras" como el db maestro, por lo que puedes arrojar todo el gran material del sistema en tiempo real a la basura a menos, por ejemplo, tu núcleo de producción la base de datos se encuentra dentro del maestro. Para mí, no puedo lidiar con la vida sin las cosas del sistema. Por supuesto, no todo el procesamiento requiere un rendimiento sin carrete y los resultados rápidos y lentos se pueden combinar simultáneamente en capas de clases de datos más altas.

Answer 10

Si su herramienta (ssms etc.) no controla los fallos cambio de esquema en el objeto de base así/elegantemente que podría causar un poco de caos real.Eso es con lo que estoy sentado ahora, y me doy cuenta de que se trata de un caso marginal