¿Es buena idea estos índices?

Sin conocer mas datos, no parece nada malo esos indices, igual te aconsejo
que al hacer la instruccion Sql que haga la consulta, revises muy bien el
plan de ejecucion.

Salu2

Maximiliano Damian Accotto


"Naimps" <"@naimps@"@terra.es> escribió en el mensaje
news:2xhsa2kbqj45.8rqs582b278j$

Muy buenas.

Supongo que haría falta más información, pero haber si más o menos esto
basta. Tengo las siguientes tablas:

billetes (140000 registros):
id int identity (1, 1) not null,
fecha smalldatetime not null,
ida int not null,
vuelta int not null,
estado char(1) not null,
agencia smallint not null,
usuario tinyint not null

pasajero (140000 registros):
id int identity (1, 1) not null,
nombre varchar (50) not null
tarifa_ida smallint not null,
tarifa_vuelta smallint not null,
billetes_id int not null

coche:
id int identity (1, 1) not null,
matricula varchar (10) not null
tarifa smallint not null,
billetes_id int not null

animal:
id int identity (1, 1) not null,
tarifa tinyint not null,
billetes_id int not null

viajes:
id int identity(1, 1) not null,
linea tinyint not null,
fecha smalldatetime,
hora datetime

Un billete tiene un único pasajero y/o un único coche y/o un único animal.

La tabla billetes se busca, para una consulta de previsión de embarque,

por

el estado (igual a E), y por la ida y vuelta (claves externas de una tabla
que contiene los viajes).

La tabla de pasajero está ligada a la de billetes (billetes_id) a una

única

tabla de tarifas (tarifa_ida indica la tarifa de la ida y tarifa_vuelta la
de la vuelta).

Y lo mismo con las de vehículos y animales.

Yo había pensado, en la de de viajes, crear el PK en id, y luego una
agrupada con "fecha, linea" (¿o mejor "linea, fecha"?).

En la de billetes, PK para id, y luego una agrupada: "ida, vuelta, estado"
(para optimizar la búsqueda por fechas de salida y estado).

¿Es buena idea? ¿O una tontería?

Gracias.

On Thu, 12 Feb 2004 09:48:05 -0300, Maximiliano D. A. wrote:

Sin conocer mas datos, no parece nada malo esos indices, igual te aconsejo
que al hacer la instruccion Sql que haga la consulta, revises muy bien el
plan de ejecucion.

Salu2

¿Sería buena idea, además del indice agrupado "ida, vuelta, estado" en la
tabla de billetes, crear índices para "ida", "vuelta" y "estado" (crear 3
índices más)?

On Thu, 12 Feb 2004 09:48:05 -0300, Maximiliano D. A. wrote:

Sin conocer mas datos, no parece nada malo esos indices, igual te aconsejo
que al hacer la instruccion Sql que haga la consulta, revises muy bien el
plan de ejecucion.

Salu2

Acabo de añadir el índice agrupado (ida, vuelta, estado), y al ejecutar al
consulta obtengo estos valores:

Antes índice:
Table 'ic_barco'. Scan count 16, logical reads 32, physical reads 0,
read-ahead reads 0.
Table 'ic_acomodaciones'. Scan count 16, logical reads 32, physical reads
0, read-ahead reads 0.
Table 'ic_numaco'. Scan count 32, logical reads 256, physical reads 0,
read-ahead reads 0.
Table 'ic_viabil'. Scan count 4, logical reads 4824, physical reads 0,
read-ahead reads 0.
Table 'ic_billetes'. Scan count 6, logical reads 2243, physical reads 0,
read-ahead reads 0.
Table 'ic_viaje'. Scan count 8, logical reads 32, physical reads 0,
read-ahead reads 0.
Table 'ic_viagrup'. Scan count 8, logical reads 16, physical reads 0,
read-ahead reads 0.
Table '#0A8AE248'. Scan count 4, logical reads 4, physical reads 0,
read-ahead reads 0.

Después índices:
Table 'ic_barco'. Scan count 6, logical reads 12, physical reads 0,
read-ahead reads 0.
Table 'ic_acomodaciones'. Scan count 6, logical reads 12, physical reads 0,
read-ahead reads 0.
Table 'ic_numaco'. Scan count 12, logical reads 122, physical reads 0,
read-ahead reads 7.
Table 'ic_viabil'. Scan count 2, logical reads 2410, physical reads 1,
read-ahead reads 1202.
Table 'ic_billetes'. Scan count 8, logical reads 108, physical reads 4,
read-ahead reads 2.
Table 'ic_viaje'. Scan count 8, logical reads 16, physical reads 0,
read-ahead reads 0.
Table 'ic_viagrup'. Scan count 8, logical reads 16, physical reads 0,
read-ahead reads 0.
Table '#17E4DD66'. Scan count 4, logical reads 4, physical reads 0,
read-ahead reads 0.

Los "logical reads" ha disminuido en varias tablas (enntre ellas
"billetes"), pero han aparecido en "physical reads" y en "read-ahead
reads". ¿Es bueno o malo? ¿Qué significan?

Gracias.

Hola:
El uso de un Indice adicional sobre la tabla viajes, dependera de la
cantidad de filas que tenga esta tabla, si son menos de 20,000 proablemente
no vale la pena agregar ningun indice, porque las filas son lo
suficientemente pequenas. Me parece que son como 5000 filas por Extension
(grupos de 8 paginas de 8 Kb).
Si son mas filas, los indices dependeran del forma en que se consulten
los datos y de los datos mismos. Particularmente si hay pocas lineas (menos
de 10/20) es probable que un indice sobre este campo no se use mucho.
Fecha-Linea o Fecha-Hora-Linea serian candidatos, e incluso es posible que
sea mejor definirlos como Clustered Index (Indice Compuesto), pero esto
depende de la aplicacion.
En la tabla de billetes parece mala idea usar estado ya que seguramente
solo tiene 2 valores, y las columnas poco selectivas no son ultiles para los
indices. Una llave Ida-Id y otra Vuelta-ID parecieran mejores opciones.
Estas opiniones deben ser comprobadas con datos, pero serian las
primeras opciones que buscaria.
No voy a comentar sobre el diseno de la Tablas ni sobre el uso del
Identity, pero de ninguna manera significa que los apruebe :(.

Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.


Naimps" <"@naimps@ <"@naimps@"@terra.es> escribio:

Muy buenas.

Supongo que haría falta más información, pero haber si más o menos
esto basta. Tengo las siguientes tablas:

billetes (140000 registros):
id int identity (1, 1) not null,
fecha smalldatetime not null,
ida int not null,
vuelta int not null,
estado char(1) not null,
agencia smallint not null,
usuario tinyint not null

pasajero (140000 registros):
id int identity (1, 1) not null,
nombre varchar (50) not null
tarifa_ida smallint not null,
tarifa_vuelta smallint not null,
billetes_id int not null

coche:
id int identity (1, 1) not null,
matricula varchar (10) not null
tarifa smallint not null,
billetes_id int not null

animal:
id int identity (1, 1) not null,
tarifa tinyint not null,
billetes_id int not null

viajes:
id int identity(1, 1) not null,
linea tinyint not null,
fecha smalldatetime,
hora datetime

Un billete tiene un único pasajero y/o un único coche y/o un único
animal.

La tabla billetes se busca, para una consulta de previsión de
embarque, por el estado (igual a E), y por la ida y vuelta (claves
externas de una tabla que contiene los viajes).

La tabla de pasajero está ligada a la de billetes (billetes_id) a una
única tabla de tarifas (tarifa_ida indica la tarifa de la ida y
tarifa_vuelta la de la vuelta).

Y lo mismo con las de vehículos y animales.

Yo había pensado, en la de de viajes, crear el PK en id, y luego una
agrupada con "fecha, linea" (¿o mejor "linea, fecha"?).

En la de billetes, PK para id, y luego una agrupada: "ida, vuelta,
estado" (para optimizar la búsqueda por fechas de salida y estado).

¿Es buena idea? ¿O una tontería?

Gracias.

"[...] No voy a comentar sobre el diseno de la Tablas ni sobre el uso del
Identity, pero de ninguna manera significa que los apruebe :( [...]"

Ah, pero... ¿tú no eras de los partidarios de su uso? ;-)


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

Por favor, responder únicamente al foro
Se agradece la inclusión de sentencias DDL


"Javier Loria" escribió en el mensaje
news:#

Hola:
El uso de un Indice adicional sobre la tabla viajes, dependera de la
cantidad de filas que tenga esta tabla, si son menos de 20,000

proablemente

no vale la pena agregar ningun indice, porque las filas son lo
suficientemente pequenas. Me parece que son como 5000 filas por Extension
(grupos de 8 paginas de 8 Kb).
Si son mas filas, los indices dependeran del forma en que se consulten
los datos y de los datos mismos. Particularmente si hay pocas lineas

(menos

de 10/20) es probable que un indice sobre este campo no se use mucho.
Fecha-Linea o Fecha-Hora-Linea serian candidatos, e incluso es posible que
sea mejor definirlos como Clustered Index (Indice Compuesto), pero esto
depende de la aplicacion.
En la tabla de billetes parece mala idea usar estado ya que

seguramente

solo tiene 2 valores, y las columnas poco selectivas no son ultiles para

los

indices. Una llave Ida-Id y otra Vuelta-ID parecieran mejores opciones.
Estas opiniones deben ser comprobadas con datos, pero serian las
primeras opciones que buscaria.
No voy a comentar sobre el diseno de la Tablas ni sobre el uso del
Identity, pero de ninguna manera significa que los apruebe :(.

Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.


Naimps" <"@naimps@ <"@naimps@"@terra.es> escribio:
> Muy buenas.
>
> Supongo que haría falta más información, pero haber si más o menos
> esto basta. Tengo las siguientes tablas:
>
> billetes (140000 registros):
> id int identity (1, 1) not null,
> fecha smalldatetime not null,
> ida int not null,
> vuelta int not null,
> estado char(1) not null,
> agencia smallint not null,
> usuario tinyint not null
>
> pasajero (140000 registros):
> id int identity (1, 1) not null,
> nombre varchar (50) not null
> tarifa_ida smallint not null,
> tarifa_vuelta smallint not null,
> billetes_id int not null
>
> coche:
> id int identity (1, 1) not null,
> matricula varchar (10) not null
> tarifa smallint not null,
> billetes_id int not null
>
> animal:
> id int identity (1, 1) not null,
> tarifa tinyint not null,
> billetes_id int not null
>
> viajes:
> id int identity(1, 1) not null,
> linea tinyint not null,
> fecha smalldatetime,
> hora datetime
>
> Un billete tiene un único pasajero y/o un único coche y/o un único
> animal.
>
> La tabla billetes se busca, para una consulta de previsión de
> embarque, por el estado (igual a E), y por la ida y vuelta (claves
> externas de una tabla que contiene los viajes).
>
> La tabla de pasajero está ligada a la de billetes (billetes_id) a una
> única tabla de tarifas (tarifa_ida indica la tarifa de la ida y
> tarifa_vuelta la de la vuelta).
>
> Y lo mismo con las de vehículos y animales.
>
> Yo había pensado, en la de de viajes, crear el PK en id, y luego una
> agrupada con "fecha, linea" (¿o mejor "linea, fecha"?).
>
> En la de billetes, PK para id, y luego una agrupada: "ida, vuelta,
> estado" (para optimizar la búsqueda por fechas de salida y estado).
>
> ¿Es buena idea? ¿O una tontería?
>
> Gracias.