Hola. Quería pedir el final de la 1er fecha de Febrero o bien si pueden comentar como fue.
Muchas gracias.
Hola, envio el final que tomaron. No se si las respuestas que escribí son correctas.
Espero que te sirva.
Atte
Paula
Muchas gracias por el aporte. Aporto mi resolución "on the fly".
1)
a) F. Contraejemplo: select count(*) from tabla
b) F.
2)
a) Performance.
b) Triggers, constraints (podrían ser también vistas y procedimientos pero estos sirven mas que nada para el acceso de datos)
3) Supongo que la respuesta es la A. Si la tabla esta vacía, al querer insertar un dato NULL en una columna que no los admite "rompe". Por lo tanto la transacción 2 no termina de ejecutarse por completo. La transacción 1 se ejecuta sin problemas y el resultado del count seria el mismo para ambas sentencias.
4) Trigger que nos impida un hacer insert/update de un valor que no sea consecutivo a los de la tabla (cuando llego a casa lo desarrollo).
Gente, subo el final scaneado por si alguno lo quiere imprimir.
Éxitos para los que vayan a rendir !
[
attachment=8163]
¿La respuesta al ejercicio 3 no sería la D "No hay suficiente información"?
Porque dependiendo del isolation level (que no lo menciona en el ejercicio) el proceso 1 puede o no ver lo que insertó el proceso 2.
podes justificar eso, o podes tomar el default value de isolation level (el cual como hice gdd hace 2 años no recuerdo ahora).
Pasa que el default value depende del motor, y no te dicen que es (uno asumiria que es sql server por la sintaxis y porque se ve en la cursada, pero tecnicamente...)
Recuerdo alguna vez a uno de los profes de gdd diciendo que podian valer cualquiera de las 2 respuestas, si estan bien justificadas
Hola, alguno tiene la resolución del punto 4??
gracias!!!!
yo haría un trigger instead of insert, y que haga un insert de count(*) + 1
algo asi (no me acuerdo bien la sintaxis, puede que algo pifie, es pseudo codigo arre)
create trigger dbo.SoloNaturalesInsert on Tabla
instead of Insert
as
begin
insert into Tabla select count (*) + 1 from tabla
dice que se acceden de distintas maneras
asique se podria borrar un elemento.
Eso significa que deahi en adelante tenes que retrasar todos los elementos en -1
nuevamente, haria un trigger instead of delete
create trigger dbo.SoloNaturalesDelete on Tabla
instead of Delete
as
begin
delete from tabla where col1 in (select col 1 from deleted) -- el in siempre deberia traer un solo elemento
-- actualizamos desde donde borramos en adelante, retrasando 1 siempre
update Tabla set col1 = col1 - 1 where col1 in (select col1 + 1 from deleted)
end
no estoy seguro, me da fiaca
pero creo que se puede hacer con un "after delete" y solo haciendo el update
y para el update lo mismo.. imagino que habrá que updatear los valores desde ese valor en adelante.. asique es otro trigger
Para el ejercicio 4, un trigger que se comporta de una manera un poco mas copada, si lo que insertas es el siguiente o los siguientes numeros al ultimo que tiene la tabla, te lo inserta, sino no hace nada (se podria mandar un error tambien)... Esta testeado en sql server y anda bien![/code]
Lo unico que tiene es que no contempla el caso de que tengas un conjunto sin huecos pero que no empiece desde cero (ejemplo 456) y quieras agregar desde abajo (por ejemplo 23, para que queden 23456)... Esto ya era demasiado complejo.
Falta el trigger instead of update (que no deberia hacer nada, solo sustituir la operacion update por un mensaje de error)
create trigger trigger_insertnumber on TABLA_FINAL
instead of insert
as
declare @numero int
declare curs cursor for select numero from inserted order by numero asc
open curs
fetch next from curs into @numero
if(((select max(numero) from TABLA_FINAL) is NULL) and (@@FETCH_STATUS = 0))
begin
if (@numero = 0)
begin
insert into TABLA_FINAL(numero) values (@numero)
fetch next from curs into @numero
end
end
while @@FETCH_STATUS = 0
begin
if(@numero = (select max(numero) from TABLA_FINAL) + 1)
begin
insert into TABLA_FINAL(numero) values (@numero)
end
fetch next from curs into @numero
end
close curs
deallocate curs
go
create trigger trigger_deletenumber on TABLA_FINAL
instead of delete
as
declare @numero int
declare curs cursor for select numero from deleted order by numero desc
open curs
fetch next from curs into @numero
while @@FETCH_STATUS = 0
begin
if(@numero = (select max(numero) from TABLA_FINAL))
begin
delete from TABLA_FINAL where numero = @numero
end
fetch next from curs into @numero
end
close curs
deallocate curs
go
para que vas a hacer un cursor recorriendolos todos si al estar numerados, sabiendo la cantidad de filas ya sabes cuanto vale el ultimo ?
(22-02-2014 22:16)gonnza escribió: [ -> ]yo haría un trigger instead of insert, y que haga un insert de count(*) + 1
algo asi (no me acuerdo bien la sintaxis, puede que algo pifie, es pseudo codigo arre)
create trigger dbo.SoloNaturalesInsert on Tabla
instead of Insert
as
begin
insert into Tabla select count (*) + 1 from tabla
dice que se acceden de distintas maneras
asique se podria borrar un elemento.
Eso significa que deahi en adelante tenes que retrasar todos los elementos en -1
nuevamente, haria un trigger instead of delete
create trigger dbo.SoloNaturalesDelete on Tabla
instead of Delete
as
begin
delete from tabla where col1 in (select col 1 from deleted) -- el in siempre deberia traer un solo elemento
-- actualizamos desde donde borramos en adelante, retrasando 1 siempre
update Tabla set col1 = col1 - 1 where col1 in (select col1 + 1 from deleted)
end
no estoy seguro, me da fiaca pero creo que se puede hacer con un "after delete" y solo haciendo el update
y para el update lo mismo.. imagino que habrá que updatear los valores desde ese valor en adelante.. asique es otro trigger
Me parece buenísimo la resolución con los triggers
pero me agarró una duda en el de delete.
por ejemplo se insertaron ya:
1
2
3
4
5
6
Y alguien hace un delete al 4, ok, el trigger de delete borra el 4 y hace el update al 5 poniendolo en 4, pero me deja el 6 dejando un hueco
1
2
3
4
6
O hay algo que no estoy viendo?
Gracias!
no solo tenes razon, sino que yo no me fío de mi propio comentario que dice "el in siempre deberia traer un solo elemento, actualizamos desde donde borramos en adelante, retrasando 1 siempre"
porque podrían borrarse varios a la vez (where num > x) asique también estaría mal
de cualquier manera, respecto a tu pregunta puntual, se podria hacer un cursor que itere deleted, y haga set col1 = col1- 1 cuando col1 > <numero-iterado-de-deleted>
no me acuerdo la sintaxis de cursor ni a palos
el insert deberia quedar igual
debería hacerse un trigger para update también me parece
(13-02-2014 10:51)ortiba escribió: [ -> ]¿La respuesta al ejercicio 3 no sería la D "No hay suficiente información"?
Porque dependiendo del isolation level (que no lo menciona en el ejercicio) el proceso 1 puede o no ver lo que insertó el proceso 2.
No puede ser la D. Por mas que especifique el isolation level, no cambiaria nada. Porque el proceso 2 tira error (si se ejecuta el proceso 1 primero o el 2 primero).
Es la A, pq es cierto que a y b siempre son iguales, siempre valen 0.
Pero son procesos que por mas que se ejecuten en paralelo, son independientes.
Porque el proceso 2 falla, pq la tabla no tiene nada, y no puede insertar null en la tabla.
El proceso uno, solo define unas variables, pero no inserta nada en la tabla que pueda llegar a modificar la consulta del proceso 2.
corrijanme si me equivoco
Saludos
Al punto cuatro tambien habria que hacer algo con el update, porque con un update el usuario romperia todo!
Alguno me podría justificar la 2da del VoF
Gracias