2011-08-27 16 views
7

La documentación de SQL Server here dice que el campo table_schema de information_schema.tables es "no confiable" y que la forma correcta de obtener el esquema de un objeto es consultar sys.objects.informacion de esquema information_schema no confiable en SQL Server?

Puede alguien más detalles sobre cómo y cuando el esquema reportado por information_schema.tables puede ser incorrecto?

+0

En cuanto a la salida de 'sp_helptext EXEC 'INFORMATION_SCHEMA.TABLES'' este ** ** hace uso 'sys.objects' así que parece extraño. –

+0

En SQL Server 2000, técnicamente, esta columna informaba del propietario del objeto, no de su esquema, aunque en 2000 ese concepto era intercambiable de todos modos. A menos que la portabilidad cross-RDBMS sea una prioridad máxima, recomiendo utilizar las vistas del catálogo 'sys' para metadatos en lugar de' INFORMATION_SCHEMA' principalmente porque la primera se extenderá para las nuevas características, pero la última será relativamente estancada. (Como un ejemplo, intente averiguar acerca de los índices filtrados usando 'INFORMATION_SCHEMA'.) –

+0

@Martin ¿Notó que realiza una' LEFT JOIN'? Me parece que eso indica que hay algún escenario donde el esquema podría ser inválido (no puedo imaginar eso fuera de mi cabeza). Pero el mensaje de advertencia (gramática incorrecta y todo) tiene poco sentido, porque significa que la fila en 'sys.schemas' a la que apunta' sys.objects' tampoco es válida, así que ¿cómo se usa 'sys.objects' (o el más apropiado 'sys.tables') le da algo más confiable que' INFORMATION_SCHEMA'? –

Respuesta

11

Es una pena que esto no haya sido respondido y que haya sido comentado tan parcialmente fuera de la codicia del representante y, lo que es más importante, para salir de la cola sin respuesta, voy a arrojar algunos puntos en una respuesta.

  1. La redacción de la documentación no es exacta, y es en el proceso de corrección (ver Connect #686118). No estoy seguro si corregirán los documentos de R2 de 2005, 2008 y 2008, todo a la vez, o si las versiones anteriores incluso se actualizarán. El punto es que no puedo imaginar un caso en el que el esquema en cualquiera de las vistas sea incorrecto, pero aún más, ese esquema_info es incorrecto, mientras que sys.objects es correcto. Esto último es imposible: la vista info_schema se basa completamente en la vista sys.objects (solo mira SELECT OBJECT_DEFINITION (OBJECT_ID ('INFORMATION_SCHEMA.TABLES'));), por lo que si una es incorrecta, ambas son incorrectas. Probablemente haya casos poco claros en los que ambos puedan ser incorrectos, pero no en las versiones actuales (por ejemplo, en SQL Server 2000, con la opción de configuración allow updates activada, elimine de los usuarios del sistema un usuario que no sea realmente relevante o posible en la actualidad, y no es algo que estoy dispuesto a probar, pero es el único que puedo imaginar que habría motivado la redacción actual en cualquier momento).

  2. En general, se deben evitar las vistas INFORMATION_SCHEMA a favor de las vistas de catálogo introducidas en SQL Server 2005 (y aumentadas desde entonces). ¿Por qué? Porque las vistas de catálogo continúan desarrollándose a medida que se agregan nuevas características a SQL Server, mientras que las vistas de info_schema no lo hacen. Como mencioné en mi comentario, intente encontrar información sobre los índices filtrados en info_schema. Lo mismo sucede con las columnas incluidas, los índices XML, las columnas de identidad/calculadas, las claves externas frente a índices únicos; todas estas opciones faltan por completo o se representan de manera diferente en las vistas de info_schema. En Denali agregaron una vista info_schema para Sequences, pero nuevamente cumple con el mínimo estándar y no incluye información sobre los detalles de implementación específicos de SQL Server (por ejemplo, si está agotado y si agregan nuevas características en el futuro, puede estar seguro de que la vista info_schema no se mantendrá en el bucle). El único caso en el que se apegaría a las vistas de info_schema es si (a) está escribiendo rutinas de metadatos que necesitan trabajar en las plataformas compatibles con info_schema Y (b) no está utilizando ninguna característica específica de la plataforma que se perderá. Aparte de las herramientas de proveedores multiplataforma, este es probablemente un escenario bastante raro (e incluso en ese caso puede llevar a clientes descontentos que son usando esas características y la herramienta no las recogió).

  3. Presenté una sugerencia de Connect por separado (Connect #686121) que enyesan una advertencia sobre este estado incompleto en todos INFORMATION_SCHEMA ver temas en Libros en línea. No creo que sea muy conocido que sean no la forma preferida de eliminar metadatos de SQL Server, y quién podría culpar a la gente por no ver esto; después de todo, siempre nos dicen que usar métodos que cumplen con los estándares es una "mejor práctica" y el uso de métodos patentados es todo lo contrario. Al igual que con muchas cosas de la base de datos, "depende", pero sospecho que, en la mayoría de las ocasiones, es mejor que utilice las vistas del catálogo sys, a menos que se encuentre en ese raro escenario en el que solo utiliza las funciones de SQL. Servidor que son comunes al estándar.No creo haber encontrado una sola instancia en cualquier caso en que este fuera el caso, pero estoy más que feliz de aprender de ellos si es que existen.

EDITAR también he escribió en su blog acerca de la falta de fiabilidad de INFORMATION_SCHEMA aquí:

http://sqlblog.com/blogs/aaron_bertrand/archive/2011/11/03/the-case-against-information-schema-views.aspx

Cuestiones relacionadas