Buenas!

Subo el final de hoy. Yo me fui así que los resultados no los puedo confirmar.
De los V/F el 1.a creo que es falso y el 1.b no estoy segura (leí por ahí que algunos motores lo permitían, pero no recordaba cuáles).
Los teóricos están en varios apuntes.

Respecto a la práctica, punto 3.a, si bien hay un error de sintaxis en el If (dentro del select dice 'stoc_cantidad' y 'stoc_producto'), en el examen dijeron que no había errores de sintaxis, así que eso hay que descartarlo. Yo lo hice en la máquina, y me da la opción C...el tema es que no puedo entender dónde es que pincha en tiempo de ejecución. Cualquier ayuda será bienvenida

El 3.b creo que con un trigger se resuelve, todavía no lo hice.

Saludos!

Yo lo rendí y me clavaron el dos. Un salame

el 1.a es falso, podes tener deadlocks

el 1.b es falso, podes tener 1, no se el tema de los motores, a mí me la consideraron bien con poner eso.

3.a es la C, cuando a @cantidad le queres meter item_cantidad from INSERTED rompe, le queres meter a una variable un posible conjunto de valores. Si insertás una fila anda perfecto, pero si le metés un INSERT INTO item_facture SELECT bla bla, rompe.


Desaprobé porque no hice el 3.b y porque me consideraron 0.5/2 en la de plan de consulta y 1/2 en la de HASH y eso que puse lo que está en los apuntes. O sea, sumé 5.5 de los 6, una GARCHA

Hola, yo tampoco me quedé.
Agrego la de plan de ejecución por si a alguno le sirve, según lo que está en varios apuntes...

Plan de Ejecución de un SELECT
Antes de ejecutar una consulta, el motor de base de datos la optimiza. El resultado de esa optimización es lo que se conoce como plan de ejecución. Las decisiones que toma el motor para optimizar incluyen: qué algoritmo de join usar, qué algoritmo de ordenamiento usar, qué algoritmo de agrupación usar o si recorrer la tabla de forma secuencial o usando índices. Todas estas decisiones mejoran la performance de la consulta. Por ejemplo, no es lo mismo utilizar un algoritmo de join especializado para tablas de tamaño pequeño que usarlo para tablas de tamaño mayor

y de Wiki
https://es.wikipedia.org/wiki/Optimizador_de_consultas

El trigger del ultimo punto se hace con after insert y un cursor adentro por si tenes muchos inserts en Inserted.

Añado un par de comentarios sobre el final.

Una de las principales características de revisar y analizar el plan de ejecución de una consulta es poder ver cuales son los motivos por el cual la misma se demora en devolver los resultados. Básicamente te permite detectar la falta de una primary key, o un índice en una columna, ya que la misma te regresa un "Table scan". A grandes rasgos la príncipal útilidad de el plan es detectar esos pequeños errores de diseño de base de datos.

Respecto al 3A como ya dijeron la correcta es la C dado que solo se puede asignar 1 solo valor a una variable, por lo que si haces un insert directo desde una consulta el trigger rompe.

Rendí ayer y me saqué un 7 así que supongo que los VoF los tenía bien. Mis respuestas fueron:

VoF:

Los puntos 2.a) y 2.b) están en la teoría, creo que nada del otro mundo.

3.a)

3.b)


Saludos!

(15-02-2017 11:51)Martin. escribió:  Añado un par de comentarios sobre el final.

Una de las principales características de revisar y analizar el plan de ejecución de una consulta es poder ver cuales son los motivos por el cual la misma se demora en devolver los resultados. Básicamente te permite detectar la falta de una primary key, o un índice en una columna, ya que la misma te regresa un "Table scan". A grandes rasgos la príncipal útilidad de el plan es detectar esos pequeños errores de diseño de base de datos.

Respecto al 3A como ya dijeron la correcta es la C dado que solo se puede asignar 1 solo valor a una variable, por lo que si haces un insert directo desde una consulta el trigger rompe.

Yo puse lo que dijeron por arriba y estaba mal, a ellos les interesaba que pongas esto que puso martin, cuál es la utilidad o cómo impacta en el usuario el plan de ejecución. Si ponías como yo que el plan de ejecución mejoraba la performance y toda esa guitarreada, te clavaban un 0.5/2. Gracias por la respuesta.

Con el trigger me ayudan? O sea, claramente era un trigger y una forma eran los cursores. Pero se puede hacer sin cursores ? En el final hice algo así:

CREATE TRIGGER tr_bajar_stock ON item_factura AFTER INSERT
AS
BEGIN
UPDATE stock
SET stock_cantidad = stock_cantidad - P.parcial
FROM stock S
INNER JOIN
(SELECT item_producto,
SUM(CASE WHEN item_cantidad<= stock_cantidad THEN item_cantidad END)
AS parcial FROM INSERTED INNER JOIN STOCK WHERE item_producto=stock_producto
GROUP BY item_producto) P
ON s.stock_producto = P.item_producto
END

Pero el problema es justamente que P.item_producto puede tener un monton de filas y también falla.

Los profesores también dijeron que una opción era modificar todos los stock, y despues hacer otro update de los que quedaron negativos, poniendole el valor anterior, pero tampoco se me ocurre como encararlo.

Gracias !

El 3)c) no lo pude hacer,

Si alguien puede ayudar con el trigger con el cursor vendría muy bien! Gracias.

(15-02-2017 14:53)tincho543 escribió:  El 3)c) no lo pude hacer,

Si alguien puede ayudar con el trigger con el cursor vendría muy bien! Gracias.

Con el cursor vendría a ser algo así:

 

CREATE TRIGGER tr_bajar_stock ON item_factura AFTER INSERT

AS

BEGIN

DECLARE @idProducto int, @cantidad int



DECLARE cStock CURSOR FOR

	SELECT item_producto, item_cantidad from INSERTED



OPEN cStock 

FETCH cStock INTO @idProducto, @cantidad



WHILE (@@FETCH_STATUS = 0)

BEGIN



UPDATE STOCK

SET STOCK_CANTIDAD = STOCK_CANTIDAD - @CANTIDAD

WHERE STOCK_PRODUCTO = @IDPRODUCTO



FETCH cStock INTO @idProducto, @cantidad

END



CLOSE cStock 

DEALLOCATE cStock 



end

(15-02-2017 12:44)feder escribió:  Yo puse lo que dijeron por arriba y estaba mal, a ellos les interesaba que pongas esto que puso martin, cuál es la utilidad o cómo impacta en el usuario el plan de ejecución. Si ponías como yo que el plan de ejecución mejoraba la performance y toda esa guitarreada, te clavaban un 0.5/2. Gracias por la respuesta.

Con el trigger me ayudan? O sea, claramente era un trigger y una forma eran los cursores. Pero se puede hacer sin cursores ? En el final hice algo así:
[code=sql]
CREATE TRIGGER tr_bajar_stock ON item_factura AFTER INSERT
AS
BEGIN
UPDATE stock
SET stock_cantidad = stock_cantidad - P.parcial
FROM stock S
INNER JOIN
(SELECT item_producto,
SUM(CASE WHEN item_cantidad<= stock_cantidad THEN item_cantidad END)
AS parcial FROM INSERTED INNER JOIN STOCK WHERE item_producto=stock_producto
GROUP BY item_producto) P
ON s.stock_producto = P.item_producto
END

Pero el problema es justamente que P.item_producto puede tener un monton de filas y también falla.

Los profesores también dijeron que una opción era modificar todos los stock, y despues hacer otro update de los que quedaron negativos, poniendole el valor anterior, pero tampoco se me ocurre como encararlo.

Gracias !

Creo que si al trigger lo definis del tipo Instead Of Insert, funcionaría.


CREATE TRIGGER tr_bajar_stock ON item_factura INSTEAD OF INSERT
AS
BEGIN
--INSERTO PRIMERO LOS ELEMENTOS EN SU TABLA
INSERT INTO item_factura
SELECT * FROM INSERTED

--ACTUALIZO STOCK PARA CADA ELEMENTO DE LA TABLA INSERTED
UPDATE stock
SET stock_cantidad = stock_cantidad - P.parcial
FROM stock S
INNER JOIN
(SELECT item_producto,
SUM(CASE WHEN item_cantidad<= stock_cantidad THEN item_cantidad END)
AS parcial FROM INSERTED INNER JOIN STOCK WHERE item_producto=stock_producto
GROUP BY item_producto) P
ON s.stock_producto = P.item_producto
END

Cita:Con el cursor vendría a ser algo así:

 

CREATE TRIGGER tr_bajar_stock ON item_factura AFTER INSERT

AS

BEGIN

DECLARE @idProducto int, @cantidad int



DECLARE cStock CURSOR FOR

	SELECT item_producto, item_cantidad from INSERTED



OPEN cStock 

FETCH cStock INTO @idProducto, @cantidad



WHILE (@@FETCH_STATUS = 0)

BEGIN



UPDATE STOCK

SET STOCK_CANTIDAD = STOCK_CANTIDAD - @CANTIDAD

WHERE STOCK_PRODUCTO = @IDPRODUCTO



FETCH cStock INTO @idProducto, @cantidad

END



CLOSE cStock 

DEALLOCATE cStock 



end

Corrijo una boludes, como el enunciado decía que no podía haber stock menor a 0 le agregaría un par de líneas nomás y quedaría así:

 

CREATE TRIGGER tr_bajar_stock ON item_factura AFTER INSERT

AS

BEGIN TRAN

DECLARE @idProducto int, @cantidad int



DECLARE cStock CURSOR FOR

	SELECT item_producto, item_cantidad from INSERTED



OPEN cStock 

FETCH cStock INTO @idProducto, @cantidad



WHILE (@@FETCH_STATUS = 0)

BEGIN



IF (@cantidad - (SELECT stock_cantidad FROM stock WHERE stock_producto = @idProducto)) =< 0

BEGIN

UPDATE STOCK

SET STOCK_CANTIDAD = STOCK_CANTIDAD - @CANTIDAD

WHERE STOCK_PRODUCTO = @IDPRODUCTO

END

ELSE

ROLLBACK TRAN



FETCH cStock INTO @idProducto, @cantidad

END



CLOSE cStock 

DEALLOCATE cStock 



COMMIT TRAN

Saludos.

El trigger sin cursor podria ser algo asi, haciendo join con inserted.

UPDATE stock SET stock_cantidad = stock_cantidad - i.item_cantidad

FROM stock s INNER JOIN inserted i ON i.ProductoID = s.ProductoID
WHERE (s.stock_cantidad - i.item_cantidad >= 0)


De esa manera no manejas errores, simplemente el item que se pasa de stock no se tiene en cuenta

Buen día!
Sigue el método de ver el final 5 minutos e irse?
No estoy muy segura para rendir hoy, pero quería verlo.

Gracias!

hola! en que apunte puedo encontrar las diferencias del indice hash y arbol b+?

Gracias!

CREATE TRIGGER actual_stock ON item_factura instead of INSERT
AS
BEGIN TRAN
DECLARE @item_num
DECLARE @item_cant decimal(12,2)
DECLARE @item_prod int

DECLARE cursor_fact CURSOR FOR SELECT * FROM INSERTED
OPEN cursor_fact
FETCH NEXT FROM cursor_fact INTO @item_num,@item_cant,@item_prod

WHILE(@@FECHT_STATUS=0)
BEGIN
IF((SELECT stock_cantidad FROM stock WHERE stock_producto=@item_prod)-@item_cant>=0)
BEGIN
INSERT INTO item_factura VALUES(@item_num,@item_cant,@item_prod)
UPDATE stock SET stock_cantidad=stock_cantidad-@item_cant WHERE stock_producto=@item_producto
END
FETCH NEXT FROM cursor_fact INTO @item_num,@item_cant,@item_prod
END
CLOSE cursor_fact
DEALLOCATE cursor_fact
END