¿Es buena idea estos índices?

12/02/2004 - 12:24 por Naimps | Informe spam
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.

Preguntas similare

Leer las respuestas

#6 Jhonny Vargas P.
12/02/2004 - 15:55 | Informe spam
Hola Carlos,

Hay alguna desventaja en su uso?... suelo utilizar el identity en las tablas
de movimientos (asi solo realizo la consulta por un solo campo y no por
todas las relaciones)... hay algunas restricciones?.


Saludos,
Jhonny Vargas P. [MS-MVP]
Santiago de Chile
http://www.mvp.cl



"Carlos Sacristan" escribió en el mensaje
news:

"[...] 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.
>
>


Respuesta Responder a este mensaje
#7 Carlos Sacristan
12/02/2004 - 16:49 | Informe spam
Creo que deberías echarle un vistazo a un artículo que hice
(recopilación de alguno de los genios que andan por aquí) y que está
publicado en www.portalsql.com. En la búsqueda pon "naturales o
artificiales" y te aparecerá el artículo que te comento...



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


"Jhonny Vargas P." escribió en el mensaje
news:
Hola Carlos,

Hay alguna desventaja en su uso?... suelo utilizar el identity en las


tablas
de movimientos (asi solo realizo la consulta por un solo campo y no por
todas las relaciones)... hay algunas restricciones?.


Saludos,
Jhonny Vargas P. [MS-MVP]
Santiago de Chile
http://www.mvp.cl



"Carlos Sacristan" escribió en el mensaje
news:
>
> "[...] 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.
> >
> >
>
>


Respuesta Responder a este mensaje
#8 Jhonny Vargas P.
12/02/2004 - 16:50 | Informe spam
Gracias...


Saludos,
Jhonny Vargas P. [MS-MVP]
Santiago de Chile
http://www.mvp.cl



"Carlos Sacristan" escribió en el mensaje
news:

Creo que deberías echarle un vistazo a un artículo que hice
(recopilación de alguno de los genios que andan por aquí) y que está
publicado en www.portalsql.com. En la búsqueda pon "naturales o
artificiales" y te aparecerá el artículo que te comento...



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


"Jhonny Vargas P." escribió en el


mensaje
news:
> Hola Carlos,
>
> Hay alguna desventaja en su uso?... suelo utilizar el identity en las
tablas
> de movimientos (asi solo realizo la consulta por un solo campo y no por
> todas las relaciones)... hay algunas restricciones?.
>
>
> Saludos,
> Jhonny Vargas P. [MS-MVP]
> Santiago de Chile
> http://www.mvp.cl
>
>
>
> "Carlos Sacristan" escribió en el mensaje
> news:
> >
> > "[...] 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.
> > >
> > >
> >
> >
>
>


Respuesta Responder a este mensaje
#9 Jhonny Vargas P.
12/02/2004 - 17:03 | Informe spam
Leído y entendido...

Excelente artículo y muy completo...


Saludos,
Jhonny Vargas P. [MS-MVP]
Santiago de Chile
http://www.mvp.cl


"Jhonny Vargas P." escribió en el mensaje
news:e3mP7#
Gracias...


Saludos,
Jhonny Vargas P. [MS-MVP]
Santiago de Chile
http://www.mvp.cl



"Carlos Sacristan" escribió en el mensaje
news:
>
> Creo que deberías echarle un vistazo a un artículo que hice
> (recopilación de alguno de los genios que andan por aquí) y que está
> publicado en www.portalsql.com. En la búsqueda pon "naturales o
> artificiales" y te aparecerá el artículo que te comento...
>
>
>
> 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
>
>
> "Jhonny Vargas P." escribió en el
mensaje
> news:
> > Hola Carlos,
> >
> > Hay alguna desventaja en su uso?... suelo utilizar el identity en las
> tablas
> > de movimientos (asi solo realizo la consulta por un solo campo y no


por
> > todas las relaciones)... hay algunas restricciones?.
> >
> >
> > Saludos,
> > Jhonny Vargas P. [MS-MVP]
> > Santiago de Chile
> > http://www.mvp.cl
> >
> >
> >
> > "Carlos Sacristan" escribió en el mensaje
> > news:
> > >
> > > "[...] 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.
> > > >
> > > >
> > >
> > >
> >
> >
>
>


Respuesta Responder a este mensaje
#10 Naimps
12/02/2004 - 18:08 | Informe spam
On Thu, 12 Feb 2004 07:47:34 -0600, Javier Loria wrote:

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.





Acabo de añadir los índices que me comentas, 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.
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida