sql sql-server query-optimization schemabinding

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



sql-server query-optimization (10)

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", por 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 inconvenientes para SCHEMABINDING estas vistas? He encontrado algunos artículos que aluden vagamente a los inconvenientes, pero nunca los analice 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.

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

Los aspectos negativos mencionados apenas superan esta práctica recomendada desde SQL Svr 2005. Evita la temida tabla de spooling. 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.

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

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

Oh, definitivamente hay DESCENSO en el uso de SCHEMABINDING, estos provienen del hecho de que el SCHEMABINDING, especialmente cuando se combina con columnas COMPUTADAS, " CIERRA " LAS RELACIONES y hace que algunos "cambios triviales" sean casi imposibles.

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

¡Suerte con eso!

  1. La UDF no se puede quitar o modificar porque es SCHEMABOUND.
  2. La COLUMNA no se puede descartar porque se usa 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, las herramientas como ApexSQL Diff pueden manejar esto cuando se proporcionan con un esquema modificado , pero el problema es que ni siquiera puedo modificar el esquema).

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

Otro inconveniente es que necesita utilizar nombres calificados de esquema para todo: obtendrá una carga de mensajes de error como este:

No se puede vincular el esquema a la vista ''ver'' porque el nombre ''tabla'' no es válido para el enlace del esquema. Los nombres deben estar en formato de dos partes y un objeto no puede referenciarse a sí mismo.

También para ''desactivar'' el enlazado de esquemas, usted altera la vista, lo 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 es posible que deba redefinir (y posiblemente interrumpir) una gran cascada de funciones y vistas para agregar (por ejemplo, ) una restricción no nula a una columna.

Personalmente, creo que esto realmente no representa una solución y es mejor tener un proceso decente en el que los cambios en la base de datos se apliquen automáticamente, por lo que no es una pesadilla 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.

Si estas tablas son de una aplicación de terceros (son notorias por tratar de ocultar sus tablas), usted causa y la actualización falla 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. Sólo toma un poco de planificación, disciplina, etc.

Si su herramienta (ssms, etc.) no maneja bien las fallas de cambio de esquema en el objeto base, podría causar un verdadero caos. Eso es con lo que estoy sentado ahora, y me doy cuenta de que este es un caso marginal

Una desventaja 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 en esquema y me encontré con un mensaje de error que me decía 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.

esto me parece una desventaja (los '''' '''' son míos):

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.

Necesito un poco mi IZQUIERDA se une. Esta pregunta SO es relevante.