Listar las tablas de un DB determinada

Paulino, estas muy equivocado en tus comentarios y te explico porque:

1) MS recomienda que no se utilicen las tablas de sistema porque no aseguran
funcionalidad de version en version (o de SP en SP)
2) Ante la pregunta que hizo el amigo y las respuestas de Isaias yo
considero que el uso de las INFORMATION_SCHEMA son mejor por muchos motivos:

a) Es un Standard ANSI cosa que las Sysobjects no lo es
b) Sigo con las recomendaciones de MS para no utilizar de forma directa sus
tablas de sistema
c) Es mucho mas simple y visible

Ahora si vos seguis pensando de otra forma, lo respeto, pero que me digas
que respondi por responder es no conocerme en lo absoluto.
Yo no le recomiendo a ningun DBA que toque ningun SP del sistema (se nota
que no has tenido que vivir algunos procesos de migracion)

Ademas el asistente para nuevas versiones no te va a migrar tu query, ya que
no hay herramienta que detecte si sos bueno o malo programando en SqlServer
:-), a lo sumo el asistente migrara la BDD y otras yerbas pero tus SP o
querys te los tendras que migrar vos!! y si por el hecho de cambiar el SP tu
query deja de traer las BDD ahi te quiero ver :-)

Pero bue, dejalo aca, vos tenes tu opinion y yo la mia y no nos vamos a
poner en la misma sintonia (por lo menos con este tema ;-)




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)
Mail: Maxi_accotto[arroba]speedy.com.ar

Msn Messenger:

"Paulino Padial" escribió en el mensaje
news:

A ver, service packs e estado mirando y no e visto que hayan hecho un
cambio en las tablas del sistema. Microsoft, además, cuando saque una nueva
versión, habra un proceso de migración, con lo cual tampoco habra mucho
problema.
El caso y por lo que te he nombrado en mi respuesta, es porque no peudes
decir, "ummm yo cojo la primera porque si, porque si hacenun service pack
te lo van a echar abajo" sinceramente, creo que esas dos consultas y me
atrevo a decir que ni las has probado ni profundizado un poco antes de
contestar.El tema de la optimizacion tb lo he incluido a posta, para que
nuestro amigo vea un poco mas que la simple pregunta.

Es mas, si se ha trabajado un poco como BUEN administrador de Sql server,
muchas veces nos hemos visto obligados a usar tocar, e incluso incluir
partes de funcionalidad de las propias tablas del sistemas, sp del
sistemas y vistas del sistema. Por ello las usamos, y por ello podemos ver
su codigo, para poder comprender lo que hace, y ver su flujo de
funcionalidad para poder interactuar con el libremente, y modificarlo si
hace falta.

Por ello no creo que este bien decirle a alguien que pregunta una cosa
como esta decirle esa respuesta tan tajante y SUPERFICIAL, porque no es
cierto que no haya que tocarlas, es mas un buen administrador sabe como
hacer buen uso de ellas. Contestar por contestar es un error que cometemos
todos, y hemos de poder ser capaces de dar al que pregunta una respuesta
completa y además plantar en el una semilla de curiosidad y una vision mas
allá de la que tenia antes de venir aqui.

Paulino Padial


Maxi wrote:

Hola, no es una cuestion de performance aqui sino de escalabilidad y de
compatibilidad con futuras versiones de SQL, por eso no recomiendo el uso
de las tablas de sistema
"Paulino Padial" escribió en el mensaje
news:

Maxi.. no te lo tomes a mal, pero creo que con esa respuesta nuestro
amigo se habra quedao...

La diferencia claro esta, es probando por ejemplo yo voy a mostrar un
ejemplo con la Tabla Pubs para que veamos que podemos hacer.

En cuanto a cual es mas efectiva? pues bueno lanza las dos consultas
viendo el plan de ejecucion, esta es la prueba que yo he hecho :
1)

use pubs
go
set statistics io on
SELECT * FROM SYSOBJECTS WHERE xtype = 'U'

Resultado :
(11 filas afectadas)

Tabla 'sysobjects'. Número de exploraciones 2, lecturas lógicas 4,
lecturas físicas 0, lecturas anticipadas 0.
Grid:
name xtype type
titleauthor U U
stores U U
sales U U
roysched U U
discounts U U
jobs U U
pub_info U U
employee U U
authors U U
publishers U U
titles U U


2)
use pubs
go
set statistics io on
select * from INFORMATION_SCHEMA.TABLES

(14 filas afectadas)

Tabla 'sysobjects'. Número de exploraciones 1, lecturas lógicas 2,
lecturas físicas 0, lecturas anticipadas 0.
Grid
pubs dbo authors BASE TABLE
pubs dbo discounts BASE TABLE
pubs dbo employee BASE TABLE
pubs dbo jobs BASE TABLE
pubs dbo pub_info BASE TABLE
pubs dbo publishers BASE TABLE
pubs dbo roysched BASE TABLE
pubs dbo sales BASE TABLE
pubs dbo stores BASE TABLE
pubs dbo sysconstraints VIEW
pubs dbo syssegments VIEW
pubs dbo titleauthor BASE TABLE
pubs dbo titles BASE TABLE
pubs dbo titleview VIEW


Podemos ver que la mas acertada es la tabla que consulta sobre sysobjects
y no el information_schema, porque el information_Schema nos mete tb 3
vistas, y por lo tanto nos devuelve valores de más. En cambio la primera
consulta nos devuelve lo que realmente deseamos.

También podemos ver que la segunda consulta es mas efectiva, ya que hace
una exploracion y dos lecutras logicas. Entonces si lo que queremos es
mas eficiencia, y si queremos como maxi , no usar una tabla del sistema
podriamos probar a añadir un where a la segunda consulta de esta forma :

select * from INFORMATION_SCHEMA.TABLES
where Table_Type like 'BASE TABLE'
(11 filas afectadas)

Tabla 'sysobjects'. Número de exploraciones 1, lecturas lógicas 2,
lecturas físicas 0, lecturas anticipadas 0.

De esta forma estamos usando el information_schema y admeas opteniendo el
mismo rendimiento, que sigue siendo mejor que consultando la tabla del
sistema en cuanto a RENDIMIENTO.

Maxi wrote:

Hola, amigo!! el segundo ejemplo no te lo recomiendo porque estas usando
directamente las tablas del sistema, cosa que no es para nada
recomendado ya que en futuras versiones o hasta en Service Packs se
podrian modificar y tu query quedaria trunco :(

Lo mejor en estos casos es usar las vistas de sistema como has expuesto
muy bien en el ejemplo 1