SQL avanzado

8,226 views
8,112 views

Published on

Esta son las presentaciones

Published in: Education, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
8,226
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

SQL avanzado

  1. 1. ProcedimientosAlmacenados(stored procedures)<br />Un procedimiento almacenado se puede definir como un programa, procedimiento ó función, el cual está almacenado en la base de datos y listo para ser usado.<br />Utilizar parámetros de salida : Si se ejecuta una consulta de SQL ad hoc que devuelve una sola fila, debes utilizar un conjunto de resultados. Un procedimiento almacenado ofrece la posibilidad de utilizar parámetros de salida, lo que resulta ser mucho más rápido. Si ejecutas sólo una consulta, no notarás la diferencia, pero si ejecutas la consulta siguiente 2000 veces, es probable que ganes mucho devolviendo @key como parámetro de salida en lugar de un conjunto de resultados.<br />Manejar las dependencias : En un sistema complejo que incluye unos centenares de tablas, muchas veces quieres saber dónde se usa una tabla o columna determinada, por ejemplo si quieres cambiar una columna de alguna manera. Si todo el código está en procedimientos almacenados, sólo se tiene que buscar en el texto de los procedimientos para encontrar las referencias. Si envías instrucciones SQL directamente desde la aplicación, se debe buscar en una cantidad mayor de código, y si el nombre de la columna tiene un nombre común la tarea puede ser casi imposible.<br />Establecer bloques de lógico: permite esconder los detalles de las base de datos dentro de los procedimientos, así que se convierten en una capa de abstracción.<br />
  2. 2. ProcedimientosAlmacenados<br />Permisos:Un procedimiento almacenado es la solución clásica para manejar el acceso de los usuarios a los datos. Un usuario no debería tener los permisos para ejecutar SELECT, INSERT, UPDATE y DELETE directamente<br />Almacenar los planes de consulta en la caché: Otra ventaja importante de los procedimientos almacenados es el rendimiento. Cuando un procedimiento almacenado se ejecuta por la primera vez, los motores de DB crea un plan de consulta y lo almacena en la caché para poder reutilizarlo en el futuro.<br />Reducir el tráfico en la red: El tráfico en la red también afecta el rendimiento de las aplicaciones. Poner esta consulta en un procedimiento reduce la cantidad de bytes que se transmite por la red, lo que puede mejorar el rendimiento si hay mucho tráfico.<br />La diferencia es aún más evidente cuando tienes una serie de instrucciones SELECT/INSERT/UPDATE interrelacionadas. Un procedimiento almacenado te permite utilizar tablas temporales o variables de tabla para procesar todos los datos en el servidor.<br />En caso de utilizar instrucciones de SQL ad hoc(Cliente), “se tiene que enviar todos los datos entre el servidor y el cliente o la capa intermedia” esto se puede resolver creando tablas temporales sin un procedimiento almacenado, - pero se puedes tener problemas con el connectionpooling y los conjunto de registro -.<br />
  3. 3. ProcedimientosAlmacenadosPostgres<br />Un procedimiento almacenado en PostgreSQL se puede escribir en multiples lenguajes de programación. En una instalación por defecto de PostgreSQL podremos tener disponibles los siguientes lenguajes: PL/pgSQL, PL/Perl, PL/Tcl y PL/Python.<br />El único lenguaje que está disponible automáticamente es PL/pgSQL. Para utilizar PL/Perl, PL/Tcl o PL/Python tendremos que haber configurado/compilado PostgreSQL con estos parámetros --with-perl --with-tcl --with-python.<br />Tambien existen muchos otros lenguajes disponibles como módulos adicionales, entre ellos, PL/Java, PL/PHP, PL/R, PL/Ruby, PL/Sheme y PL/sh, pero estos tienen que descargarse e instalarse por separado .<br />PL/pgSQLes muy parecido al lenguaje PL/SQL utilizado por Oracle, Los objetivos de PL/pgSQL cuando se creo fueron:<br />Poder ser usado para crear funciones y disparadores (triggers)<br />Añadir estructuras de control al lenguaje SQL<br />Poder realizar cálculos complejos<br />Heredar todos los tipos, funciones y operadores definidos por el usuario<br />Poder ser definido como un lenguaje "de confianza"<br />Fácil de usar<br />
  4. 4. ProcedimientosAlmacenadosPostgres<br />PL/pgSQLes un lenguaje estructurado en bloques. Como mínimo tendremos un bloque principal en nuestro procedimiento almacenado y dentro de este podremos tener subbloques. <br />CREATE OR REPLACE FUNCTION ejemplo_txt(integer, integer) RETURNStext AS $$<br />DECLARE<br />numero1 ALIAS FOR $1; <br />numero2 ALIAS FOR $2; <br />constante CONSTANTinteger := 100;<br />resultado INTEGER; <br />resultado_txtTEXT DEFAULT 'El resultado es 104';<br />BEGIN <br />resultado := (numero1 * numero2) + constante;<br />IF resultado <> 104 <br />THENresultado_txt := 'El resultado NO es 104';<br />END IF; <br />RETURNresultado_txt; <br />END; <br />$$ LANGUAGEplpgsql;<br />
  5. 5. Tablasparticionadas<br />Normalmente las tablas particionadas se crean por que las tablas tiene un gran tamaño ademas del gran número de inserciones diarias. Permitiendo un esquema de organización de los datos en la tabla.<br />Cuando hay grandes conjuntos de datos, las operaciones frecuentes de mantenimiento (estas se realizan en los datos estáticos) puede tener efectos costosos, tales como problemas de rendimiento, problemas de bloqueo, las copias de seguridad (espacio, tiempo y costos operativos), así como un impacto negativo en la escalabilidad global del servidor.<br />Las busquedasmediante índices globales tiene un pobre desempeño ya que se revisan toda la tabla.<br />Las tablas particionadas permite dividir los datos dentro de múltiples objetos de almacenamiento llamados particiones de datos o rangos de acuerdo con los valores en una o mas columnas de la tabla.<br />Las tablas particionadas mejorar la escalabilidad y manejabilidad de las tablas grandes y las tablas que tienen diferentes patrones de acceso como las fechas.<br />Cada partición de datos se puede almacena por separado. <br />.<br />
  6. 6. Tablasparticionadas<br />proceso de consultas también pueden tomar ventaja de la separación de los datos para evitar la exploración de datos irrelevantes.<br />Con el uso de índices que incluyen las columnas de partición se reduce el ámbito de busqueda y con ello se mejora la rapidez.<br />Las particiones de tablas dan la posibilidad de ser truncadas por separado y por ello son usadas muy a menudo en tablas donde la validez de sus datos están sujetos a fechas donde el truncate de una partición no afecta al total de la tabla.<br />las particiones se dividen en una partición activa y las de archivado. <br />si una tabla grande existe en un sistema con varias CPU, la partición de la tabla puede llevar a un mejor desempeño a través de operaciones paralelas. El rendimiento de las operaciones a gran escala a través de conjuntos de datos extremadamente grandes (por ejemplo, millones de filas) se pueden beneficiar mediante la realización de múltiples operaciones en paralelo.<br />Cada N días se trunca mediante un job la partición que será la particionactiva para realizar inserts, de esta manera las otras particiones se mantendrán intactas, manteniendo así un histórico de datos para consultas limitadas por fechas y provocando menor movimiento de bloques de memoria y la desfragmentación causada por inserción o borrado de datos.<br />.<br />
  7. 7. TablasparticionadasPostgresql<br />En postgresql el tipo de partitioning soportado se denomina particionado mediante herencia de tablas. Cada partición puede ser creada como una tabla hija de una unica tabla padre. La tabla padre normalmente debe de ser una tabla vacia, que representara a todo el conjunto de datos.<br />Los dos tipos de particionado mas comunes en postgresql son:<br /> 1. Particionar por rangos. La tabla es particionada mediante rangos definidos en base a la columna de clave primaria o cualquier columna que no se solape entre los rangos de valores asignados a diferentes tablas hijas.<br /> 2. Particionar por lista. La tabla es particionada listando los valores de cada una de las claves en cada particion.<br />.<br />
  8. 8. TablasparticionadasPostgresql<br />En postgresql para poder utilizar dicha técnica es necesario seguir algunos pasos:<br /> 1. Crear la tabla "maestra", de la cual todas las tablas hijas heredaran. Esta tabla no contendra datos, no debe de tener ningun tipo de restricción (check), no debe de tener indice ni nada por el estilo.<br /> 2. Crear todas las tablas hijas heredando de la tabla maestra. Por lo regular estas tablas heredaran todos los campos de la tabla padre y no es necesario crearlos nosotros mismos.<br /> 3. Agregar a todas las tablas hijas las restricciones correspondientes sobre los datos que albergaran. Algunos ejemplos de esto serian: CHECK ( pais IN ('México', 'Argentina')), CHECK ( id_cliente BETWEEN 100 AND 200 ) ... CHECK ( id_cliente BETWEEN 5000 AND 5200), estos dos ultimos ejemplos son para evitar traslapes entre los ids de clientes.<br /> 4. Para cada particion, crear un indice para la columna(s) Clave, tambien se pueden poner los indices que a cada quien le convengan. El indiceclave primaria no es estrictamente necesario, pero en la mayoria de los casos ayuda mucho. Si se nesecita una clave unica o clave primaria, esta se necesitaras crear para cada tabla hija.<br /> 5. Definir una regla (RULE) o trigger para redirigir las modificaciones de la tabla padre (master) a la apropiada particion.<br /> 6. Verificar que este habilitado a on el parametroconstraint_exlusion (SET constraint_exclusion = on;) en el archivo de configuracionpostgresql.conf para que los querys sean optimizados para el partitioning.<br />.<br />
  9. 9. TablasparticionadasPostgresql<br />CREATE TABLE produccion(id int not null, no_serieint, id_modeloint, id_personalint, fecha_fabricacion date, fecha_salida date);<br />particionaremos en base al modelo del producto fabricado.<br />SELECT * from modelos order by id;<br />id | modelo | caracteristicas | descripcion | imagen -+<br /> 1 | ODIN | 5 litros por minuto | calentador de paso |<br />2 | DELTA 01 | 7 litros por minuto | calentador de paso | <br />3 | DELTA 01-PLUS | 9 litros por minuto | calentador de paso |<br />4 | DELTA 02 | 13 LITROS POR MINUTO | CALENTADOR DE PASO |<br />Crear las tablas hijas heredadas de la tabla "produccion", aqui es donde se crean las restricciones (CHECK) para los datos que albergaran cada tabla hija.<br />CREATE TABLE produccion_odin ( CHECK (id_modelo = 1) ) INHERITS (produccion);<br />CREATE TABLE produccion_delta01 ( CHECK (id_modelo = 2) ) INHERITS (produccion);<br />CREATE TABLE produccion_delta01plus ( CHECK (id_modelo = 3) ) INHERITS (produccion);<br />CREATE TABLE produccion_delta02 ( CHECK (id_modelo = 4) ) INHERITS (produccion);<br />Creacion clave primariapara agilizar la busqueda de registros o garantizar la unicidad de los mismos.<br />ALTER TABLE produccion_odin ADD PRIMARY KEY (id);<br />Creacion de indices los cualespordefecto son B-TREE<br />CREATE INDEX produccion_odin_id ON produccion_odin (id); <br />CREATE INDEX produccion_delta01_id ON produccion_delta01 (id);<br />CREATE INDEX produccion_delta01plus_id ON produccion_delta01plus (id); <br />CREATE INDEX produccion_delta02_id ON produccion_delta02 (id);<br />.<br />
  10. 10. TablasparticionadasPostgresql<br />Bien, ahora procederemos a crear el juego de reglas para garantizar el llenado en cascada de los datos y que cuando estos caigan en la tabla maestra sean redirigidos a sus respectivas tablas.<br />.<br />-- Regla para produccion_odin<br />CREATE RULE produccion_odin_insert_rule AS<br />ON INSERT TO produccion WHERE<br />( id_modelo = 1 )<br />DO INSTEAD<br />INSERT INTO produccion_odin VALUES ( NEW.id,<br />NEW.no_serie,<br />NEW.id_modelo,<br />NEW.id_personal,<br />NEW.fecha_fabricacion,<br />NEW.fecha_salida);<br />-- Regla para produccion_delta01<br />CREATE RULE produccion_delta01_insert_rule AS<br />ON INSERT TO produccion WHERE<br />( id_modelo = 2 )<br />DO INSTEAD<br />INSERT INTO produccion_delta01 VALUES ( NEW.id,<br />NEW.no_serie,<br />NEW.id_modelo,<br />NEW.id_personal,<br />NEW.fecha_fabricacion,<br />NEW.fecha_salida);<br />-- Regla para produccion_delta01plus<br />CREATE RULE produccion_delta01plus_insert_rule AS<br />ON INSERT TO produccion WHERE<br />( id_modelo = 3 )<br />DO INSTEAD<br />INSERT INTO produccion_delta01plus VALUES ( NEW.id,<br />NEW.no_serie,<br />NEW.id_modelo,<br />NEW.id_personal,<br />NEW.fecha_fabricacion,<br />NEW.fecha_salida);<br />-- Regla para produccion_delta02<br />CREATE RULE produccion_delta02_insert_rule AS<br />ON INSERT TO produccion WHERE<br />( id_modelo = 4 )<br />DO INSTEAD<br />INSERT INTO produccion_delta02 VALUES ( NEW.id,<br />NEW.no_serie,<br />NEW.id_modelo,<br />NEW.id_personal,<br />NEW.fecha_fabricacion,<br />NEW.fecha_salida);<br />
  11. 11. TablasparticionadasPostgresql<br />Se procede a crearuna vista quecontendratodos los valores, talcomosi se tratase de unatablaenorme:<br />CREATE VIEW produccion_total AS<br />SELECT * FROM produccion_odin<br />UNION ALL SELECT * FROM produccion_delta01<br />UNION ALL SELECT * FROM produccion_delta01plus<br />UNION ALL SELECT * FROM produccion_delta02;<br />Con esto se tiene un esquema de tablas particionadas, para terminar se habilita el obtimizador de consultas para evitar la busqueda de algun dato en todas las particiones<br />Para configurar desde psql:<br />SET constraint_exclusion = on;<br />o modificando el postgresql.conf de la siguiente manera, anexando la siguiente linea:<br />constraint_exclusion = on<br />.<br />
  12. 12. Disparadores(TRIGGERS)<br />Un trigger (o disparador) en una Base de datos , es un procedimiento que se ejecuta cuando se cumple una condición establecida al realizar una operación. <br />Los triggers pueden definirse para las operaciones de inserción (INSERT), actualización (UPDATE) o borrado (DELETE) y pueden ejecutarse antes o después de la operación.<br />Ventajas:<br /><ul><li>la entrada en vigor automática de restricciones de los datos, hace que los usuarios entren sólo valores válidos.
  13. 13. Logs automáticos de cambios a las tablas. Una aplicación puede guardar un registro corriente de cambios, creando un trigger que se dispare siempre que una tabla se modifique.
  14. 14. La notificación automática de cambios a la Base de Datos con alertas de evento en los triggers.
  15. 15. Crear un registro de auditoría de la actividad en la base de datos. Por ejemplo, se puede seguir los cambios a la tabla de pedidos mediante la actualización de la información que corrobora a una mesa de auditoría. Aplicar una regla de negocio. Por ejemplo, puede determinar cuándo una orden supera el límite de crédito del cliente y mostrar un mensaje en este sentido. Obtener datos adicionales que no está disponible dentro de una tabla o dentro de la base de datos.Porejemplo, cuando se produzca una actualización a la columna de cantidad de la tabla de elementos,puedecalcular el ajuste correspondiente a la columna precio_total. Exigir la integridad referencial. Cuando se elimina un cliente, por ejemplo, puede utilizarun disparador para eliminar las filas correspondientes (es decir, las filas que tienen el mismo ID_Cliente ) en la tabla de pedidos.</li></li></ul><li>EjemploDisparadores(TRIGGERS)<br />CREATE TABLEuser<br />(usuario_idint,<br />nombre text);<br />CREATE TABLE user_audit<br />(usuario_idint,<br />nombre text,<br />optext,<br />fechatimestamp with time zone);<br />CREATE OR REPLACE FUNCTION audita_usuarios() RETURNSTRIGGERAS$user_audit$ <br />BEGIN<br />IF (TG_OP = ''DELETE'') THEN INSERT INTO user_audit VALUES (old. usuario_id , old. nombre , TG_OP, now()); RETURN old; <br />END IF;<br />IF (TG_OP = 'UPDATE') THEN INSERT INTO user_audit VALUES (new. usuario_id , new. nombre , TG_OP, now()); <br />RETURN NEW; <br />END IF;<br />IF (TG_OP = 'INSERT') THEN INSERT INTOuser_audit VALUES (new. usuario_id , new. nombre , TG_OP, now()); RETURN NEW;<br />END IF; <br />RETURN NULL; <br />END; $user_audit$ LANGUAGE plpgsql; CREATE TRIGGER user_audit<br />BEFORE UPDATE OR INSERT OR DELETE<br />ONuser FOR EACH ROW<br />EXECUTE PROCEDUREaudita_usuarios();<br />
  16. 16. Transaccionesautónomas<br /> En ocasiones es necesario que los datos escritos por parte de una transacción sean persistentes a pesar de que la transacción se deshaga con un ROLLBACK.<br />Es muy común que, por ejemplo, en caso de que se produzca algún tipo de error queramos insertar un registro en una tabla de log con el error que se ha produccido y hacer ROLLBACK de la transacción. Pero si hacemos ROLLBACK de la transacción tambien se realiza una INSERT a un LOG. Quedando el error en la tabla de log, pero las acciones de la transacción principal retornarían a su estado anterior.<br />Utilizacion<br />Mecanismo de Logging (log de seguimiento )<br />Contador de Intentos<br />Medidor de uso del software (registrar la llamada a la aplicacion independientemente que la transacción realice commit o rollback) <br />Componentes reusables(la posibilidad de ofrecer unidades independientes de trabajo (también conocidas como cartridges) que realicen su tarea sin efecto sobre el ambiente que lo llama)<br />No, pero puedes emularlo usando dblink o algún otro mecanismo dentro de una función para establecer una segunda conexión a la BD, y hacer cosas en esa otra conexión.<br />
  17. 17. EjemploTransaccionesautónomas<br />CREATE OR REPLACE FUNCTION fn_log_error(p_functionvarchar, p_locationint, p_errorvarchar) RETURNSvoid AS $$<br />DECLARE<br />v_sqlvarchar;<br />v_returnvarchar; <br />v_errorvarchar; <br />BEGIN <br /> PERFORMdblink_connect(‘NombreConexion', 'dbname=...'); <br />v_sql := 'INSERT INTO error_log (function_name, location, error_message, error_time) ‘<br /> || 'VALUES (''' || p_function_name || ''', ' <br /> || p_location || ', ''' || p_error || ''', clock_timestamp())'; <br />SELECT INTO v_return * <br />FROMdblink_exec('NombreConexion', v_sql, false); <br /> --Obtiene el mensage de error<br />SELECT INTO v_error * <br />FROMdblink_error_message('NombreConexion'); <br /> IF position('ERROR' in v_error) > 0 OR position('WARNING' in v_error) > 0 THEN<br />RAISE EXCEPTION '%', v_error; <br /> END IF;<br />PERFORMdblink_disconnect('NombreConexion'); <br />EXCEPTION<br />WHENothersTHEN <br />PERFORMdblink_disconnect('NombreConexion'); <br />RAISE EXCEPTION '(%)', SQLERRM;<br />END; $$ LANGUAGEplpgsqlSECURITYDEFINER;<br />
  18. 18. vistas materializadas o materializedviews<br />Almacenan la definición de la vista propiamente dicha, <br />Almacenan los registros que resultan de la ejecución de la sentencia SELECT que define la vista. <br />los resultados se almacenan físicamente constituyendo una tabla real que ocupa espacio en el disco duro. <br />Si una vista (view) utiliza muchas tablas base enlazadas de forma compleja, y dicha vista va a ser utilizada frecuentemente, será muy conveniente definirla como una vista materializada. <br />Las materializedviewmejorar el rendimiento de la base de datos, ya que la sentencia SQL base de la vista sólo se ejecutará una vez.<br />Si se reutilizarse en el futuro, se necesita un mecanismo para actualizar o refrescar dicha vista materializada, ya que las tablas base de la vista pueden haber sufrido modificaciones desde la creación de la misma.<br />
  19. 19. vistas materializadas o materializedviews<br />Se comporta como un punto de vista. Es decir, los datos de la tabla cambia cuando los datos en las tablas subyacentes tienen cambios. <br />tipos de vistas materializadas: Instantánea(Snapshot) son las más simples de implementar. Ellos sólo se actualizan cuando se actualiza de forma manual. <br />Ansioso(Eager) se actualizan tan pronto como cualquier cambio se realiza en la base de datos que lo afectan. <br />Perezoso(Lazy) se actualizan cuando se confirma la transacción. <br />Muy perezoso(VeryLazy) son funcionalmente equivalentes a los Snapshot. La única diferencia es que los cambios se registran de forma incremental y son aplicado cuando la tabla se actualiza de forma manual. <br />
  20. 20. vistas materializadas o materializedviews<br />algunas consultas son muy lentas. Es posible que se haya gotado todas las técnicas estándar acelerar lasconsultas. <br />Se nesecitan la reestructuración completa de los datos.<br />Lo que terminan haciendo es almacenar bits de pre-consulta de información para  no tener  que ejecutar la consulta  cuando se necesita los datos. Normalmente, esto se le  llama "caché" fuera del mundo de bases de datos.<br />Desarrollo de una vista materializada<br />CREATE TABLEmatviews ( <br />mv_nameNAME NOT NULL PRIMARY KEY , <br />v_nameNAME NOT NULL , <br />last_refreshTIMESTAMP WITH TIME ZONE ); <br />Las columnas son :<br />mv_name: el nombre de la vista materializada<br />.v_name: el nombre de la vista en la queestabasada la vista materializada.<br />last_refresh: es la ultimavez(tiempo) en que la vista materilizadafueactulizada.<br />
  21. 21. vistas materializadas o materializedviews<br />Funcioncreate_matview <br />esta función revisa si hay una vista materializada con ese nombre . Si es así, se produce una excepción. De lo contrario, crea una nueva tabla de la vista, e inserta una fila en la tabla matviews ..<br />CREATE OR REPLACE FUNCTION create_matview(NAME, NAME)<br />RETURNS VOID <br />SECURITY DEFINER <br />LANGUAGE plpgsql AS ' <br />DECLARE <br />matviewALIAS FOR $1; <br />view_nameALIAS FOR $2; <br />entrymatviews%ROWTYPE; <br />BEGIN <br />SELECT * INTO entry FROM matviews WHERE mv_name = matview;<br />IF FOUND THEN <br />RAISE EXCEPTION ‘Vista Materializada ''''%'''' ya exite.'',<br />matview; <br />END IF;<br />EXECUTE ''REVOKE ALL ON '' || view_name || '' FROM PUBLIC'';<br />EXECUTE ''GRANT SELECT ON '' || view_name || '' TO PUBLIC''; <br />EXECUTE ''CREATE TABLE '' || matview || '' AS SELECT * FROM '' || view_name; <br />EXECUTE ''REVOKE ALL ON '' || matview || '' FROM PUBLIC''; <br />EXECUTE ''GRANT SELECT ON '' || matview || '' TO PUBLIC''; <br />INSERT INTO matviews (mv_name, v_name, last_refresh) <br />VALUES (matview, view_name, CURRENT_TIMESTAMP); <br />RETURN; <br />END '; <br />
  22. 22. vistas materializadas o materializedviews<br />Funciondrop_matvie <br />esta función elimina la vista materilizada y la remueve de la tabla matviews  ..<br />CREATE OR REPLACE FUNCTION drop_matview(NAME) RETURNS VOID <br />SECURITY DEFINER <br />LANGUAGE plpgsql AS ‘<br />DECLARE matview ALIAS FOR $1; <br />entry matviews%ROWTYPE; <br />BEGIN <br />SELECT * INTO entry FROM matviews WHERE mv_name = matview; <br />IF NOT FOUND THEN <br />RAISE EXCEPTION '‘Vista materilizada% no existe.'', matview; <br />END IF;<br />EXECUTE ''DROP TABLE '' || matview;<br />DELETE FROM matviews WHERE mv_name=matview; <br />RETURN;<br />END '; '; <br />
  23. 23. vistas materializadas o materializedviews<br />Funcionrefresh_matview<br />Esta funcion actualiza o carga  las vistas materializadas para que los datos no se convierta en obsoletos.<br />Utiliza un algoritmo de fuerza bruta que eliminarán todas lasfilas y vuelva y las recarga con los datos de la vista ejecutada.Tenga en cuenta que es posible que desee eliminar los índices en la vistamaterializada antes de la ejecución de esta funcion, y los vuelve a recrear después de que termine de ejecutar esta funcion.<br />CREATE OR REPLACE FUNCTION refresh_matview(name) RETURNS VOID<br />SECURITY DEFINER <br />LANGUAGE plpgsql AS ' <br />DECLARE matview ALIAS FOR $1;<br />entrymatviews%ROWTYPE; <br />BEGIN <br />SELECT * INTO entry FROM matviews WHERE mv_name = matview; <br />IF NOT FOUND THEN RAISE EXCEPTION ‘Vista materializada % no existe.'', matview; <br />END IF; <br />EXECUTE ''DELETE FROM '' || matview; <br />EXECUTE ''INSERT INTO '' || matview || '' SELECT * FROM '' || entry.v_name;<br />UPDATE matviews<br />SET last_refresh=CURRENT_TIMESTAMP WHERE mv_name=matview; <br />RETURN;<br />END ';<br />
  24. 24. vistas materializadas o materializedviews<br />Ejemplo de una vista materializadatipo Snapshot <br />CREATE TABLE jugadores( pname VARCHAR(255) PRIMARY KEY ); <br />CREATE TABLE juego_resultado( pname VARCHAR(255) NOT NULL, score INTEGER NOT NULL ); <br />CREATE VIEW jugadores_total_puntaje_vAS SELECT pname, sum(score) AS total_score FROM game_score GROUP BY pname; <br />En estecaso los juagdoresjuegancadadia y correruna vista esdemasidocostoso en rendimiento y desempeño, porconsiguente se decide imprementaruna vista materializadapara el puntaje total de cadajugador (jugadores_total_puntaje_v).<br />Se ejecutan los siguinetescomandos:<br />SELECT create_matview('jugadores_total_puntaje_mv', 'jugadores_total_puntaje_v'); <br />CREATE INDEX pname_idx ON player_total_score_mv(pname);<br />Cadanoche (o cadahoradepende de como los jugadoresmirar los resultados) , se deberefrescar la vista materializada con el siguinetecomando.<br />DROP INDEX pname_idx ON jugadores_total_puntaje_mv; <br />SELECT refresh_matview('jugadores_total_puntaje_mv'); <br />CREATE INDEX pname_idx ON jugadores_total_puntaje_mv(pname); Even though the scores in player_total_score_mv isn't going to change to reflect the most current scores until the refresh is run, the players will learn to accept that.<br />';<br />
  25. 25. Recursividad<br />La recursividad permite la capacidad de poder seleccionar un conjunto de datos de forma recursiva de manera que podemos obtener una serie de datos en estructura de árbol. La devolución de datos jerárquicos es un uso frecuente de las consultas recursivas; por ejemplo, mostrar los empleados en un organigrama o los datos en un escenario de lista de materiales en donde un producto primario tiene uno o varios componentes que, a su vez, tienen subcomponentes o son componentes de otros elementos primarios.<br />Una solución es una expresión de tabla común (CTE) , esta ofrece la gran ventaja de poder hacer referencia a sí misma, creando así una CTE recursiva. Una CTE recursiva es aquélla en la que una CTE inicial se ejecuta varias veces para devolver subconjuntos de datos hasta que se obtenga el conjunto de resultados completo.<br />Se considera que una consulta es recursiva cuando hace referencia a un CTE recursiva. <br />Una CTE recursiva puede simplificar en gran medida el código necesario para ejecutar una <br />consulta recursiva en una instrucción SELECT, INSERT, UPDATE, DELETE o CREATE VIEW.<br /> Anteriormente la solución utilizaba tablas temporales, cursores y lógica para controlar el flujo<br />de los pasos recursivos. <br />
  26. 26. EjemploRecursividad<br />CREATE TABLE empleado( <br />id_Empleado INTEGER PRIMARY KEY, -- ID empleado<br />Nombre TEXT,<br />Apellido TEXT,<br /> Cargo TEXT, <br />parent_EmpleadoINTEGER REFERENCES empleado, -- upper department ID <br />DeptIDINTEGER,-- department name ); <br />FirstNamenvarchar(30) NOT NULL, LastNamenvarchar(40) NOT NULL, Title nvarchar(50) NOT NULL, DeptIDsmallint NOT NULL, ManagerIDint NULL,. <br />
  27. 27. EjemploRecursividad<br />La jerarquía en colombia<br />La jerarquía es algo así:<br />El mundo contiene<br />Colombia, que contienen...<br />departamentos, que contienen...<br />Municipios, que contienen...<br /> Barrios<br />CREATE  TABLE lugares (  <br />    id INTEGER PRIMARY KEY,   <br />    parent_lugares INTEGER REFERENCES lugares,  <br />    nombre TEXT   <br />   );  <br />
  28. 28. EjemploRecursividad<br />INSERT INTO lugares VALUES (0, NULL, ‘COLOMBIA');<br />INSERT INTO  lugares  VALUES (1, 0, 'ANTIOQUIA');    <br />INSERT INTO  lugares  VALUES (2, 1, ‘AMAGA');    <br />INSERT INTO  lugares  VALUES (3, 1, ‘MEDELLIN');    <br />INSERT INTO  lugares  VALUES (4, 1, ‘ENVIGADO');    <br />INSERT INTO  lugares  VALUES (5, 0, ‘BOGOTA');    <br />INSERT INTO  lugares  VALUES (6, 5, ‘SOACHA');    <br />INSERT INTO  lugares  VALUES (7, 3, ‘LAURELES'); <br />Extraer todos los municipios de antioquia<br />CREATE  VIEW vMunicipiosAntioquia AS  <br />    WITH RECURSIVE MunicipiosAntioquia AS  <br />    (         <br />        SELECT * FROM lugares WHERE nombre = ‘ANTIOQUIA'  <br />        UNION ALL     <br />        SELECT d.* FROM lugares AS d, MunicipiosAntioquia AS sd  <br />            WHERE d.parent_lugares = sd.id  <br />    )  <br />    SELECT * FROM MunicipiosAntioquia;  <br />SELECT * FROM vlugaresORDER BY nombre; <br />

×