UTNianos

Versión completa: [APORTE] Final Gestion de Datos 02/10/2012
Actualmente estas viendo una versión simplificada de nuestro contenido. Ver la versión completa con el formato correcto.
Gente, les dejo adjunto el final de gdd que tomaron ayer. El archivo tiene puesta la resolucion que hice del 3-a. Y los V o F eran ambos falsos.

Si ven el nombre del doc, no es que me haya equivocado: tomaron exactamente el mismo final que en mayo del 2007!
Gracias! Mirá vos, el mismo final que uno pasado..

1.B: Se considera que es el peor al ser NxN la complejidad, es decir, es "tan peor" como el ordenamiento por "burbuja". ¿No. Entonces por que sería F?

3.B: ¿Habría que hacer un trigger ante INSERT y UPDATE para evitar negativos y ID=RENGLON?. Luego para los registros ya existentes, ¿habría que modificar (con sentencias UPDATE) los valores de COLUMNA1 y COLUMNA2 en caso de que fueran negativos?
(03-10-2012 20:36)Ident escribió: [ -> ]Gracias! Mirá vos, el mismo final que uno pasado..

1.B: Se considera que es el peor al ser NxN la complejidad, es decir, es "tan peor" como el ordenamiento por "burbuja". ¿No. Entonces por que sería F?

3.B: ¿Habría que hacer un trigger ante INSERT y UPDATE para evitar negativos y ID=RENGLON?. Luego para los registros ya existentes, ¿habría que modificar (con sentencias UPDATE) los valores de COLUMNA1 y COLUMNA2 en caso de que fueran negativos?


El 1b era falso porque no es el peor de todos. Tanto el heapsort como el quick sort como el arbol B tienen ese grado de complejidad en el peor caso, por lo que no hay un "peor de todos". El burbujeo es una desgracia para la humanidad =P


Para el 3b tenias que hacer un trigger para el insert y update para que si habia negativos o el ID era menor al reglon saltara un mensaje de error y no permita que eso se guarde. Con el tema de los ya existentes... mira, no podes modificar lo que ya existe (que le pondrias ?????), yo lo que hice fue hacer una consulta preguntando si existe algun registro que cumpla lo que no tiene que pasar, y si es asi que levante un mensaje avisando. Tambien podrias optar por borrar los incorrectos, pero no se si te lo aceptaban.
En realidad el heapsort tiene siempre la misma complejidad (n.log n) pero si, el razonamiento es ese. No puede ser el peor de todos los metodos si hay uno igual de malo.

Para el 3b, yo borre los datos de la tabla que estaban incorrectos y despues hice un trigger con rollback, pero creo que me pusieron q estaba mal (a juzgar por la nota ya que la teoria la tenia bastante bien)
En mi curso dijeron que todos los metodos tenian los mismos grados de complejidad

n log n el mejor

n^2 el peor

n raiz (n) como el caso promedio
(03-10-2012 12:54)tenchology escribió: [ -> ]Gente, les dejo adjunto el final de gdd que tomaron ayer. El archivo tiene puesta la resolucion que hice del 3-a. Y los V o F eran ambos falsos.

Si ven el nombre del doc, no es que me haya equivocado: tomaron exactamente el mismo final que en mayo del 2007!

Como resolviste el 3a, no entiendo, si te dice que tienen que estar en las columnas los que valores que vienen por parametro, porque aparece el ultimo registro si ningun valor de columna1y2 coincide con los valores1 y 2? Es por el al menos una vez? aparte tambien dice, que se encuentren coincidencia para ambas columnas, y en la primera solo se encuentra para el 234? y el 700?
Que zarna q son estos queries!!!!
Hola!
El 3-a) tenes q pensarlo asi:
1 1 234 500
1 2 345 600
1 3 332 700 en este grupo tenes una columna con 234 y otra columna con 700, dentro del grupo..entonces lo muestro

2 2 31 700
2 3 45 400 en este grupo NO tenes una columna con 234 y otra columna con 700, dentro del grupo..entonces NO lo muestro

3 3 56 600
3 4 234 700 en este grupo tenes una columna con 234 y otra columna con 700, dentro del grupo..entonces lo muestro


El 3-b)
para validar los registros ya existentes, ¿se puede hacer un SP que haga una consulta y vaya poniendo en una tabla los registros errores?
Ah...ok...es por el grupo de registros, no por cada registro.
gracias.
URLs de referencia