Sobre vistas

Respondiendo a tus preguntas:

Es preferible hacer una sola vista que abarque todas las posibilidades en
vez de 3 vistas especializadas?

No, siempre es preferible tener las consultas exactas para lo que se
pide. La opción que comentas es una facilidad para el desarrollador de la
base de datos, el cual se quita la necesidad de crear nuevos objetos, pero
para el motor lo que estás haciendo es obligándole a hacer más cosas de las
estrictamente necesarias. Es un caso similar al poner el asterisco (* ) en
el SELECT... si no se usan todos los campos, ¿por qué pedirlos?

Aunque no se utilice un join, la vista hace el seek a la tabla
relacionada?

Eso lo puedes ver tú mismo fácilmente analizando el plan de ejecución de
la consulta. Comprobarás que sí que accede a la tabla del join, aunque no
pidas ningún campo de ella.

Se debe tener alguna prevencion de la cantidad de vistas que se definan en
una base de datos?

Hombre, lo suyo es llevar un control de qué hacen y para qué sirven cada
una de esas vistas

Pueden disminuir el rendimiento?

No. Una vista (si no está indexada) no es más que una definición de una
consulta para poder usarla luego, pero no disminuyen por sí mismas el
rendimiento. Otra cosa es el uso que se haga de ellas.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"Enrique" wrote in message
news:

Para fines de consultas y reportes en las aplicaciones que trabajo siempre
acostumbro a definir vistas de la base de datos sobre todo para las tablas
relacionadas o joins. A veces hago varias vistas sobre una misma tabla
dependiendo del uso que le vaya a dar le incluyo una u otra relacionada.
Por ejemplo la tabla A se relaciona con la B,C,D,E.
Le tengo 3 vistas de acuerdo a las relaciones que normalmente necesito
para consultas y reportes.
(los conjuntos de campos pueden ser distintos para cada vista)
Vista1: A joined a B
Vista2: A joined a B,C
Vista3: A joined a D,E

Y podría haber mas.

Las preguntas son:
Es preferible hacer una sola vista que abarque todas las posibilidades en
vez de 3 vistas especializadas? Aunque no se utilice un join, la vista
hace el seek a la tabla relacionada?

Se debe tener alguna prevencion de la cantidad de vistas que se definan en
una base de datos?

Pueden disminuir el rendimiento?

Gracias por los datos.

Por lo que veo a veces puede ser preferible, cuando varían mucho, armar las
consultas desde la propia aplicacion.


"Carlos Sacristan" escribió en el mensaje
news:

Respondiendo a tus preguntas:

Es preferible hacer una sola vista que abarque todas las posibilidades en
vez de 3 vistas especializadas?

No, siempre es preferible tener las consultas exactas para lo que se
pide. La opción que comentas es una facilidad para el desarrollador de la
base de datos, el cual se quita la necesidad de crear nuevos objetos, pero
para el motor lo que estás haciendo es obligándole a hacer más cosas de
las estrictamente necesarias. Es un caso similar al poner el asterisco
(* ) en el SELECT... si no se usan todos los campos, ¿por qué pedirlos?

Aunque no se utilice un join, la vista hace el seek a la tabla
relacionada?

Eso lo puedes ver tú mismo fácilmente analizando el plan de ejecución
de la consulta. Comprobarás que sí que accede a la tabla del join, aunque
no pidas ningún campo de ella.

Se debe tener alguna prevencion de la cantidad de vistas que se definan
en una base de datos?

Hombre, lo suyo es llevar un control de qué hacen y para qué sirven
cada una de esas vistas

Pueden disminuir el rendimiento?

No. Una vista (si no está indexada) no es más que una definición de una
consulta para poder usarla luego, pero no disminuyen por sí mismas el
rendimiento. Otra cosa es el uso que se haga de ellas.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"Enrique" wrote in message
news:

Para fines de consultas y reportes en las aplicaciones que trabajo
siempre acostumbro a definir vistas de la base de datos sobre todo para
las tablas relacionadas o joins. A veces hago varias vistas sobre una
misma tabla dependiendo del uso que le vaya a dar le incluyo una u otra
relacionada.
Por ejemplo la tabla A se relaciona con la B,C,D,E.
Le tengo 3 vistas de acuerdo a las relaciones que normalmente necesito
para consultas y reportes.
(los conjuntos de campos pueden ser distintos para cada vista)
Vista1: A joined a B
Vista2: A joined a B,C
Vista3: A joined a D,E

Y podría haber mas.

Las preguntas son:
Es preferible hacer una sola vista que abarque todas las posibilidades en
vez de 3 vistas especializadas? Aunque no se utilice un join, la vista
hace el seek a la tabla relacionada?

Se debe tener alguna prevencion de la cantidad de vistas que se definan
en una base de datos?

Pueden disminuir el rendimiento?

Cuidado con esto. Si la variedad de consultas es muy, muy grande, entonces
sí podría ser una opción; si no lo es tanto, piensa mejor en crear
procedimientos almacenados para el acceso a esos datos.

El problema de crearlo desde la aplicación, si no se usan consultas
preparadas, es que obligas al motor a compilar cada petición que le llega.
Echa un vistazo al artículo http://www.sommarskog.se/dynamic_sql.html, muy
aclaratorio en este sentido.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"Enrique" wrote in message
news:%

Gracias por los datos.

Por lo que veo a veces puede ser preferible, cuando varían mucho, armar
las consultas desde la propia aplicacion.


"Carlos Sacristan" escribió en el mensaje
news:

Respondiendo a tus preguntas:

Es preferible hacer una sola vista que abarque todas las posibilidades
en vez de 3 vistas especializadas?

No, siempre es preferible tener las consultas exactas para lo que se
pide. La opción que comentas es una facilidad para el desarrollador de la
base de datos, el cual se quita la necesidad de crear nuevos objetos,
pero para el motor lo que estás haciendo es obligándole a hacer más
cosas de las estrictamente necesarias. Es un caso similar al poner el
asterisco (* ) en el SELECT... si no se usan todos los campos, ¿por qué
pedirlos?

Aunque no se utilice un join, la vista hace el seek a la tabla
relacionada?

Eso lo puedes ver tú mismo fácilmente analizando el plan de ejecución
de la consulta. Comprobarás que sí que accede a la tabla del join, aunque
no pidas ningún campo de ella.

Se debe tener alguna prevencion de la cantidad de vistas que se definan
en una base de datos?

Hombre, lo suyo es llevar un control de qué hacen y para qué sirven
cada una de esas vistas

Pueden disminuir el rendimiento?

No. Una vista (si no está indexada) no es más que una definición de
una consulta para poder usarla luego, pero no disminuyen por sí mismas el
rendimiento. Otra cosa es el uso que se haga de ellas.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"Enrique" wrote in message
news:

Para fines de consultas y reportes en las aplicaciones que trabajo
siempre acostumbro a definir vistas de la base de datos sobre todo para
las tablas relacionadas o joins. A veces hago varias vistas sobre una
misma tabla dependiendo del uso que le vaya a dar le incluyo una u otra
relacionada.
Por ejemplo la tabla A se relaciona con la B,C,D,E.
Le tengo 3 vistas de acuerdo a las relaciones que normalmente necesito
para consultas y reportes.
(los conjuntos de campos pueden ser distintos para cada vista)
Vista1: A joined a B
Vista2: A joined a B,C
Vista3: A joined a D,E

Y podría haber mas.

Las preguntas son:
Es preferible hacer una sola vista que abarque todas las posibilidades
en vez de 3 vistas especializadas? Aunque no se utilice un join, la
vista hace el seek a la tabla relacionada?

Se debe tener alguna prevencion de la cantidad de vistas que se definan
en una base de datos?

Pueden disminuir el rendimiento?

Hola Enrique
Si usas .NET en realidad los dataset de Ado.net no hacen otra cosa que armar
las consultas en la aplicacion, eso no es tan grave de por si, lo importante
es usar parametros no solo para que puedan reutilizarse sino tambien para
evitar codigo inseguro.

"Enrique" escribió en el mensaje
news:%

Gracias por los datos.

Por lo que veo a veces puede ser preferible, cuando varían mucho, armar
las consultas desde la propia aplicacion.


"Carlos Sacristan" escribió en el mensaje
news:

Respondiendo a tus preguntas:

Es preferible hacer una sola vista que abarque todas las posibilidades
en vez de 3 vistas especializadas?

No, siempre es preferible tener las consultas exactas para lo que se
pide. La opción que comentas es una facilidad para el desarrollador de la
base de datos, el cual se quita la necesidad de crear nuevos objetos,
pero para el motor lo que estás haciendo es obligándole a hacer más
cosas de las estrictamente necesarias. Es un caso similar al poner el
asterisco (* ) en el SELECT... si no se usan todos los campos, ¿por qué
pedirlos?

Aunque no se utilice un join, la vista hace el seek a la tabla
relacionada?

Eso lo puedes ver tú mismo fácilmente analizando el plan de ejecución
de la consulta. Comprobarás que sí que accede a la tabla del join, aunque
no pidas ningún campo de ella.

Se debe tener alguna prevencion de la cantidad de vistas que se definan
en una base de datos?

Hombre, lo suyo es llevar un control de qué hacen y para qué sirven
cada una de esas vistas

Pueden disminuir el rendimiento?

No. Una vista (si no está indexada) no es más que una definición de
una consulta para poder usarla luego, pero no disminuyen por sí mismas el
rendimiento. Otra cosa es el uso que se haga de ellas.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"Enrique" wrote in message
news:

Para fines de consultas y reportes en las aplicaciones que trabajo
siempre acostumbro a definir vistas de la base de datos sobre todo para
las tablas relacionadas o joins. A veces hago varias vistas sobre una
misma tabla dependiendo del uso que le vaya a dar le incluyo una u otra
relacionada.
Por ejemplo la tabla A se relaciona con la B,C,D,E.
Le tengo 3 vistas de acuerdo a las relaciones que normalmente necesito
para consultas y reportes.
(los conjuntos de campos pueden ser distintos para cada vista)
Vista1: A joined a B
Vista2: A joined a B,C
Vista3: A joined a D,E

Y podría haber mas.

Las preguntas son:
Es preferible hacer una sola vista que abarque todas las posibilidades
en vez de 3 vistas especializadas? Aunque no se utilice un join, la
vista hace el seek a la tabla relacionada?

Se debe tener alguna prevencion de la cantidad de vistas que se definan
en una base de datos?

Pueden disminuir el rendimiento?