Crear una vista en un sp

Hola Xavi:
Y si el "administrador" que agrega la vista es un Trabajo de SQL (Job)?,
No tiene que se un procedimiento o si?
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.

Xavi escribio:

La verdad es que estoy bastante de acuerdo con tu punto de vista. En
casos generales, las bases lógicas de la ingeniería funcionan pero,
en según qué casos, hay que salirse un poco de las pautas marcadas.

En mi caso, estoy trabajando con una vista particionada. Podría
asumir que esta vista estuviera creada de un principio, con eso no
discuto.

La situación es la siguiente: Tenemos un resultado enorme de
registros que resulta inmanejable. La solución que se ha optado es de
crear una vista particionada. Por motivos muy internos, es necesario
hacer la partición por mes. Cada mes, se crea una nueva tabla que se
añade a la vista. Esto debe ser AUTOMÁTICO, es decir, no debe existir
la responsabilidad del DBA que, el día 1 de cada mes a las 00:00:01
añada la nueva tabla creada a la vista. Sin duda, es un stored quien
debe hacer esta faena.

¿No compartís mi planteamiento? ¿Existe alguna opción más válida?

Gracias por vuestros comentarios


Xavi




"Gustavo Larriera [MVP SQL]" escribió en el
mensaje news:

/* Lo que voy a opinar es estrictamente filosófico */

Creo que todo lo que sea esquema de la base de datos (tablas, vistas,
indices, etc.) es por naturaleza estático, por lo tanto definible en
tiempo de diseño y no en ejecución. Por eso opino que objetos como
una vista debería estar creado de antemano.

En tu caso mencionas que "se trata de una vista que debe existir
siempre ". Eso es mérito suficiente para que la crees al definir el
esquema de tu base de datos.

Observa que NO ES NATURAL planearlo de esta manera: Que cada sproc
verifique si los objetos que precisa están disponibles y si no lo
están, que el sproc se encargue de crearlos. No es esta la forma
habitual de programar en una base de datos.

Muy cordiales saludos
gux

Gustavo Larriera
Uruguay LatAm
http://sqljunkies.com/weblog/gux/
Este mensaje se proporciona "COMO ESTA" sin garantias y no otorga
ningun derecho / This posting is provided "AS IS" with no
warranties, and confers no rights.
"Xavi" wrote in message
news:

Hey! Pues con SQL dinámico sí es posible. Pues no lo dudo ni un
segundo. No sé por qué dices que no recomiendas ni crear una vista
en un sp ni usar SQL dinámico.

Respecto a lo primero, se trata de una vista que debe existir
siempre y que, en caso de no existir, se crea automáticamente. Es
justo que el sp la cree si no existe.

Respecto a SQL dinámico, yo siempre había sido muy reacio a usarlo
por la creencia de su bajo rendimiento. Después de leer algunos
articulos y hacer algunas pruebas, he llegado a la conclusión de
que en según que casos, valo muchísimo la pena. El argumento en el
que se basan es en que según como sea la sp, dificilmente se
aprovechará el plan de ejecución ya trazado e igualmente se tendrá
que recompilar. Estoy hablando de sp con múltiples parámetros con
posibilidad a ser opcionales.

Hay una referencia aquí. Vosotros que sois más entendidos que yo
seguramente podráis dar un punto de vista mucho más válido.

http://www.hayes.ch/sql/sql_dinamico.html

Agradezco cualquier comentario.


Xavi




"Carlos Sacristan" <csacristan ARROBA mvps.org> escribió en el
mensaje news:%

Tú lo has dicho: no es posible crear una vista desde un
procedimiento almacenado, pero si lo necesitas, puedes utilizar
SQL dinámico, aunque no te lo recomiendo (ni crear una vista desde
un procedimiento ni usar SQL dinámico)


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


"Xavi" escribió en el mensaje
news:#h4$

Hola,

Ejecuto el siguiente código y no funciona

CREATE PROCEDURE dbo.prueba
AS
CREATE VIEW vista AS
SELECT a = 0

En cambio, el código

CREATE VIEW vista AS
SELECT a = 0

sí que funciona. ¿Acaso no es posible crear una vista en un stored
procedure?

Gracias


Xavi

Javier, tienes razón. De todas maneras, parece ser que no será tan
determinista como yo pensaba sino que será posible insertar en meses
futuros. Así que será la sp quien se encargue de comprobar la existencia de
la tabla correspondiente al mes. En caso de no existir, la creará y
modificará la vista para añadir la nueva tabla.

Gracias


"Javier Loria" escribió en el mensaje
news:%23$

Hola Xavi:
Y si el "administrador" que agrega la vista es un Trabajo de SQL

(Job)?,

No tiene que se un procedimiento o si?
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.

Xavi escribio:
> La verdad es que estoy bastante de acuerdo con tu punto de vista. En
> casos generales, las bases lógicas de la ingeniería funcionan pero,
> en según qué casos, hay que salirse un poco de las pautas marcadas.
>
> En mi caso, estoy trabajando con una vista particionada. Podría
> asumir que esta vista estuviera creada de un principio, con eso no
> discuto.
>
> La situación es la siguiente: Tenemos un resultado enorme de
> registros que resulta inmanejable. La solución que se ha optado es de
> crear una vista particionada. Por motivos muy internos, es necesario
> hacer la partición por mes. Cada mes, se crea una nueva tabla que se
> añade a la vista. Esto debe ser AUTOMÁTICO, es decir, no debe existir
> la responsabilidad del DBA que, el día 1 de cada mes a las 00:00:01
> añada la nueva tabla creada a la vista. Sin duda, es un stored quien
> debe hacer esta faena.
>
> ¿No compartís mi planteamiento? ¿Existe alguna opción más válida?
>
> Gracias por vuestros comentarios
>
>
> Xavi
>
>
>
>
> "Gustavo Larriera [MVP SQL]" escribió en el
> mensaje news:
>> /* Lo que voy a opinar es estrictamente filosófico */
>>
>> Creo que todo lo que sea esquema de la base de datos (tablas, vistas,
>> indices, etc.) es por naturaleza estático, por lo tanto definible en
>> tiempo de diseño y no en ejecución. Por eso opino que objetos como
>> una vista debería estar creado de antemano.
>>
>> En tu caso mencionas que "se trata de una vista que debe existir
>> siempre ". Eso es mérito suficiente para que la crees al definir el
>> esquema de tu base de datos.
>>
>> Observa que NO ES NATURAL planearlo de esta manera: Que cada sproc
>> verifique si los objetos que precisa están disponibles y si no lo
>> están, que el sproc se encargue de crearlos. No es esta la forma
>> habitual de programar en una base de datos.
>>
>> Muy cordiales saludos
>> gux
>>
>> Gustavo Larriera
>> Uruguay LatAm
>> http://sqljunkies.com/weblog/gux/
>> Este mensaje se proporciona "COMO ESTA" sin garantias y no otorga
>> ningun derecho / This posting is provided "AS IS" with no
>> warranties, and confers no rights.
>> "Xavi" wrote in message
>> news:
>>> Hey! Pues con SQL dinámico sí es posible. Pues no lo dudo ni un
>>> segundo. No sé por qué dices que no recomiendas ni crear una vista
>>> en un sp ni usar SQL dinámico.
>>>
>>> Respecto a lo primero, se trata de una vista que debe existir
>>> siempre y que, en caso de no existir, se crea automáticamente. Es
>>> justo que el sp la cree si no existe.
>>>
>>> Respecto a SQL dinámico, yo siempre había sido muy reacio a usarlo
>>> por la creencia de su bajo rendimiento. Después de leer algunos
>>> articulos y hacer algunas pruebas, he llegado a la conclusión de
>>> que en según que casos, valo muchísimo la pena. El argumento en el
>>> que se basan es en que según como sea la sp, dificilmente se
>>> aprovechará el plan de ejecución ya trazado e igualmente se tendrá
>>> que recompilar. Estoy hablando de sp con múltiples parámetros con
>>> posibilidad a ser opcionales.
>>>
>>> Hay una referencia aquí. Vosotros que sois más entendidos que yo
>>> seguramente podráis dar un punto de vista mucho más válido.
>>>
>>> http://www.hayes.ch/sql/sql_dinamico.html
>>>
>>> Agradezco cualquier comentario.
>>>
>>>
>>> Xavi
>>>
>>>
>>>
>>>
>>> "Carlos Sacristan" <csacristan ARROBA mvps.org> escribió en el
>>> mensaje news:%
>>>> Tú lo has dicho: no es posible crear una vista desde un
>>>> procedimiento almacenado, pero si lo necesitas, puedes utilizar
>>>> SQL dinámico, aunque no te lo recomiendo (ni crear una vista desde
>>>> un procedimiento ni usar SQL dinámico)
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>> "Xavi" escribió en el mensaje
>>>> news:#h4$
>>>>> Hola,
>>>>>
>>>>> Ejecuto el siguiente código y no funciona
>>>>>
>>>>> CREATE PROCEDURE dbo.prueba
>>>>> AS
>>>>> CREATE VIEW vista AS
>>>>> SELECT a = 0
>>>>>
>>>>> En cambio, el código
>>>>>
>>>>> CREATE VIEW vista AS
>>>>> SELECT a = 0
>>>>>
>>>>> sí que funciona. ¿Acaso no es posible crear una vista en un stored
>>>>> procedure?
>>>>>
>>>>> Gracias
>>>>>
>>>>>
>>>>> Xavi

Xavi, en cualquier caso se sigue pudiendo crear un trabajo programado
para realizar esa tarea, añadiendo un paso de tipo TSQL


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


"Xavi" escribió en el mensaje
news:

Javier, tienes razón. De todas maneras, parece ser que no será tan
determinista como yo pensaba sino que será posible insertar en meses
futuros. Así que será la sp quien se encargue de comprobar la existencia

de

la tabla correspondiente al mes. En caso de no existir, la creará y
modificará la vista para añadir la nueva tabla.

Gracias


"Javier Loria" escribió en el mensaje
news:%23$
> Hola Xavi:
> Y si el "administrador" que agrega la vista es un Trabajo de SQL
(Job)?,
> No tiene que se un procedimiento o si?
> 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.
>
> Xavi escribio:
> > La verdad es que estoy bastante de acuerdo con tu punto de vista. En
> > casos generales, las bases lógicas de la ingeniería funcionan pero,
> > en según qué casos, hay que salirse un poco de las pautas marcadas.
> >
> > En mi caso, estoy trabajando con una vista particionada. Podría
> > asumir que esta vista estuviera creada de un principio, con eso no
> > discuto.
> >
> > La situación es la siguiente: Tenemos un resultado enorme de
> > registros que resulta inmanejable. La solución que se ha optado es de
> > crear una vista particionada. Por motivos muy internos, es necesario
> > hacer la partición por mes. Cada mes, se crea una nueva tabla que se
> > añade a la vista. Esto debe ser AUTOMÁTICO, es decir, no debe existir
> > la responsabilidad del DBA que, el día 1 de cada mes a las 00:00:01
> > añada la nueva tabla creada a la vista. Sin duda, es un stored quien
> > debe hacer esta faena.
> >
> > ¿No compartís mi planteamiento? ¿Existe alguna opción más válida?
> >
> > Gracias por vuestros comentarios
> >
> >
> > Xavi
> >
> >
> >
> >
> > "Gustavo Larriera [MVP SQL]" escribió en el
> > mensaje news:
> >> /* Lo que voy a opinar es estrictamente filosófico */
> >>
> >> Creo que todo lo que sea esquema de la base de datos (tablas, vistas,
> >> indices, etc.) es por naturaleza estático, por lo tanto definible en
> >> tiempo de diseño y no en ejecución. Por eso opino que objetos como
> >> una vista debería estar creado de antemano.
> >>
> >> En tu caso mencionas que "se trata de una vista que debe existir
> >> siempre ". Eso es mérito suficiente para que la crees al definir el
> >> esquema de tu base de datos.
> >>
> >> Observa que NO ES NATURAL planearlo de esta manera: Que cada sproc
> >> verifique si los objetos que precisa están disponibles y si no lo
> >> están, que el sproc se encargue de crearlos. No es esta la forma
> >> habitual de programar en una base de datos.
> >>
> >> Muy cordiales saludos
> >> gux
> >>
> >> Gustavo Larriera
> >> Uruguay LatAm
> >> http://sqljunkies.com/weblog/gux/
> >> Este mensaje se proporciona "COMO ESTA" sin garantias y no otorga
> >> ningun derecho / This posting is provided "AS IS" with no
> >> warranties, and confers no rights.
> >> "Xavi" wrote in message
> >> news:
> >>> Hey! Pues con SQL dinámico sí es posible. Pues no lo dudo ni un
> >>> segundo. No sé por qué dices que no recomiendas ni crear una vista
> >>> en un sp ni usar SQL dinámico.
> >>>
> >>> Respecto a lo primero, se trata de una vista que debe existir
> >>> siempre y que, en caso de no existir, se crea automáticamente. Es
> >>> justo que el sp la cree si no existe.
> >>>
> >>> Respecto a SQL dinámico, yo siempre había sido muy reacio a usarlo
> >>> por la creencia de su bajo rendimiento. Después de leer algunos
> >>> articulos y hacer algunas pruebas, he llegado a la conclusión de
> >>> que en según que casos, valo muchísimo la pena. El argumento en el
> >>> que se basan es en que según como sea la sp, dificilmente se
> >>> aprovechará el plan de ejecución ya trazado e igualmente se tendrá
> >>> que recompilar. Estoy hablando de sp con múltiples parámetros con
> >>> posibilidad a ser opcionales.
> >>>
> >>> Hay una referencia aquí. Vosotros que sois más entendidos que yo
> >>> seguramente podráis dar un punto de vista mucho más válido.
> >>>
> >>> http://www.hayes.ch/sql/sql_dinamico.html
> >>>
> >>> Agradezco cualquier comentario.
> >>>
> >>>
> >>> Xavi
> >>>
> >>>
> >>>
> >>>
> >>> "Carlos Sacristan" <csacristan ARROBA mvps.org> escribió en el
> >>> mensaje news:%
> >>>> Tú lo has dicho: no es posible crear una vista desde un
> >>>> procedimiento almacenado, pero si lo necesitas, puedes utilizar
> >>>> SQL dinámico, aunque no te lo recomiendo (ni crear una vista desde
> >>>> un procedimiento ni usar SQL dinámico)
> >>>>
> >>>>
> >>>> 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
> >>>>
> >>>>
> >>>> "Xavi" escribió en el mensaje
> >>>> news:#h4$
> >>>>> Hola,
> >>>>>
> >>>>> Ejecuto el siguiente código y no funciona
> >>>>>
> >>>>> CREATE PROCEDURE dbo.prueba
> >>>>> AS
> >>>>> CREATE VIEW vista AS
> >>>>> SELECT a = 0
> >>>>>
> >>>>> En cambio, el código
> >>>>>
> >>>>> CREATE VIEW vista AS
> >>>>> SELECT a = 0
> >>>>>
> >>>>> sí que funciona. ¿Acaso no es posible crear una vista en un stored
> >>>>> procedure?
> >>>>>
> >>>>> Gracias
> >>>>>
> >>>>>
> >>>>> Xavi
>
>