Listar las tablas de un DB determinada

select * from INFORMATION_SCHEMA.TABLES

SELECT * FROM SYSOBJECTS WHERE xtype = 'U'

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


Salu2
Maxi
Buenos Aires - Argentina
Desarrollador Microsoft 3 Estrellas .NET
Nunca consideres el estudio como una obligación sino como
una oportunidad para penetrar en el bello y maravillosos
mundo del saber.
- Albert Einstein



"Isaias" escribió en el mensaje
news:

select * from INFORMATION_SCHEMA.TABLES

SELECT * FROM SYSOBJECTS WHERE xtype = 'U'

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.795 / Virus Database: 539 - Release Date: 12/11/2004

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

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

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