Actualizando BBDD decidi explorar en que versión de Postgresql esta ahora (la última versión que he usado fue la 8.3.7). Cada vez postgresql me sorprende con su soporte muy parecido al Oracle. Claro desde un punto de vista Open Source es una BBDD muy buena y orientada a objetos.
A continuación mostrare las nuevas mejoras de esta versión:
Esta nueva versión 9 incluye:
- Replicación basada en envío de logs. Este avance consiste en dos características: Replicación en flujo (replication streaming), que permite un archivado continuo (WAL) de ficheros en streaming a través de una conexión de red hacia servidores en estado de alerta (stand by) y Hot Standby permitiendo que los servidores en estado de alerta de archivado continuo de fichero ejecuten consultas de solo lectura. El efecto en la red es soportar un único servidor maestro y múltiples esclavos de solo lectura.
- Gestión más sencilla de los permisos de objetos de la base de datos. GRANT/REVOKE IN SCHEMA soporta cambios masivos de permisos en los objetos existentes, mientra que ALTER DEFAULT PRIVILEGES permite el control de privilegios para objetos que se crearán en un futuro. Los objetos grandes como BLOBs, también soportan ahora la gestión de permisos.
- En términos generales, soporte mejorado de procedimientos almacenados. La sentencia DO soporta los bloques de código “anonimo” o “ad-hoc”. Ahora, las funciones pueden ser llamadas usando parámetros nombrados (identificados) PL/pgSQL ahora se instala por defecto y PL/Perl y PL/Python han sido mejorados de muchas maneras, incluyendo soporte para Python 3.
- Soporte completo para Ms Windows de 64 bits.
- Consultas de informes más avanzadas, incluyendo opciones adicionales de “windowing” (PRECEDING y FOLLOWING) y la capacidad de controlar el orden en el que los valores son introducidos en funciones (aggregate functions)
- Nuevas características de disparadores (trigger) incluyendo disparadores por columna SQL-standard-compliant y ejecución de triggers condicional.
- Restricciones (constraints) únicas diferibles. Ahora son posibles las actualizaciones masivas de claves únicas sin realizar trucos o artimañas.
- Restricciones de Exclusión. Esto provee una versión generalizada de restricciones únicas, permitiendo el cumplimiento de condiciones complejas.
- Características nuevas y mejoradas de seguridad, incluyendo autenticación mediante RADIUS, mejoras en la autenticación LDAP y un nuevo módulo “contrib”, passwordcheck, para testeo de fortaleza de las contraseñas.
- Una nueva implementación de alto rendimiento de la LISTEN/NOTIFY. Ahora, los eventos pendientes se almacenan en colas basadas en memoria en vez de en una tabla. Además, una cadena de “payload” puede ser enviada con cada evento en vez de transmitir solo un nombre de evento como antes.
- Nueva implementación de VACUUM FULL. Ahora, este comando reescribe la tabla completa y los índices, en vez de mover filas individuales a un espacio compacto. Es sustancialmente más rápido en la mayoría de casos, y no más resultados más grandes de lo necesario en índices hinchados.
- Nuevo módulo “contrib” pg_upgrade para soportar actualizaciones “in-place” desde las versiones 8.3 o 8.4 a la versión 9.0
- Mejoras múltiples del rendimiento para tipos específicos de consultas, incluyendo la eliminación de “joins” innecesarios. Esto ayuda a optimizar algunas consultas autogeneradas, como las que se producen por ORMs (object-relational mappers)
- Mejoras en EXPLAIN. La salida está ahora disponible en formato JSON, XML o YAML e incluye la utilización de buffer y otros datos que no estaban disponibles previamente.
- Mejoras en hstore, incluyendo nuevas funciones y mayor capacidad de datos.
Fuente: http://goo.gl/qc8fU (Para mas detalles)
Hace un momento un compañero de trabajo me comenta lo siguiente:
- Tengo una tabla que contiene los campos CODIGO, DESCRIPCION, FECHA. En realidad, hay mas campos pero lo que importa es el campo FECHA.
- La tabla es para hacer un reporte que tenga como filtro FECHA, se tiene las siguientes casuísticas:
- El campo FECHA no siempre tiene datos.
- El campo FECHA si no tiene datos es nulo.
- El campo FECHA es de tipo DATE
- En el reporte se desea filtrar por una FECHA determinada o sino se coloca nada en FECHA mostrar todos registros (incluyendo las fechas con nulos)
Entonces, el problema nace cuando el campo FECHA esta vacio. Como crear un query para que cumpla ambos casos siempre. Incialmente me mostro lo siguiente:
select *
from tabla_1
where fecha like v_variable
*v_variable es la variables del campo FECHA de la aplicación.
La idea esta bien si el campo FECHA fuese STRING, pero podria haberlo convertido también el campo, pero al final con esa setencia SQL no salía. Entonces habria que crear un artificio que cuando el campo FECHA mande vacio no entre al WHERE. La idea de la nueva sentencia quedaria asi:
select *
from tabla_1
where 1 = 1
and (
case
when ’ ’ = v_variable then 1
else fecha
end
) = (
case
when ’ ’ = v_variable then 1
else v_variable
end
)
Lo que se quiere hacer con esta nueva sentencia es que si v_variable es vacío entonces reemplazar el campo por 1 y de igual manera la camparación seria 1.
Cual es el objetivo en este caso y en otros, es obviar los filtros del WHERE usando CASE.
Espero que ayude a alguien también.
Hoy dia a eso de las 10am, un analista de un cliente me dice que mi pase a QAS esta con incidencia, donde me indica que cambie el BETWEEN por el “>= <=”. Le discuti un poco, pero me indico que era mas lento usar BETWEEN.
Es por ello, me puse a navegar unos 10min y encontre el sgte. enlace:
Diferencias entre BETWEEN y >= <=
Donde el autor trabaja en Oracle Argentina y es DBA/Desarrollador.
En conclusión, hizo las pruebas correspondientes y al final, es un mito que uno de los dos es mas lento. Ambos son iguales, ninguno es mas lento que el otro.
Tendria que analizar el impacto que hizo el autor, pero en mi BBDD porque aca tengo mas de 50mil registros en JOINS….
Vamos a ver que pasa, pero creo que es mas que suficiente la prueba que hizo el autor.







