Continuando con los tips para optimizar nuestras querys SQL, trataremos unas de las clásulas que más ralentizan éstas. El operador LIKE.

La definición que exponen en la TechNet me gusta y dice asi:

Determina si una cadena de caracteres específica coincide con un patrón especificado. Un patrón puede contener caracteres normales y caracteres comodín. Durante la operación de búsqueda de coincidencias de patrón, los caracteres normales deben coincidir exactamente con los caracteres especificados en la cadena de caracteres. Sin embargo, los caracteres comodín pueden coincidir con fragmentos arbitrarios de la cadena. La utilización de caracteres comodín hace que el operador LIKE sea más flexible que los operadores de comparación de cadenas = y !=.

Como se tiene que trabajar con cadenas de texto, dentro de otras cadenas más grandes normalmente, es un proceso lento para la comparación. Muchas veces (Continuar Leyendo sobre Optimizar las querys con cláusula LIKE en SQL [SQL-Tunning])

Si lo que necesitas es obtener una o un par de filas de tu base de datos de manera “randomica”  existen muchas soluciones que se pueden implementar, desde hacer un “select silvestre” y desde alguna aplicación que utilice algoritmos que permitan seleccionar un registro de manera aleatoria, hasta “cocinarlo” en desde la misma base de datos.

Dependiendo el contexto de trabajo es conveniente elegir una opción u otra. Pero ésta vez quiero centrarme más bien en hacer el trabajo desde la Base de Datos, con un Query SQL para los distintos (Continuar Leyendo sobre Obtener un registro de la base de datos aleatoriamente mediante SQL)

Más de uno me mirará con una cara ¿De que hablas, Willis? preguntándose que es un particionamiento horizontal de tablas. Se le llama así cuando tenemos tablas que almacenan un conjunto demasiado grande de registros (en millones) y éste comienza a tener un bajo rendimiento, es entonces cuando se decide partir la tabla en tablas más pequeñas en cuanto a su almacenamiento de datos se refiere.

Para comprender completamente el concepto de Particionamiento Horizontal necesitaremos el conocimiento previo de herencia de tablas en éste motor, lo pueden leer aquí si lo desean.

Hace unos meses hablaba con un amigo y colega sobre sus tareas en una empresa de gran porte en donde tiene millones de filas creadas al día, el rubro es la telefonía celular y almacenan los mensajes de texto para luego trabajar con ellos, me mencionaban que iban partiendo sus tablas de manera manual separado en meses y el DBA (Continuar Leyendo sobre Particionamiento Horizontal de Tablas en PostgreSQL)

Este es el artículo nº 200 publicado en Devtroce y deseo escribir sobre algún tema de base de datos, y pensé en particionamiento horizontal en Postgre pero el mismo requiere conocimientos sobre herencias de tablas para llevarlo a cabo, entonces decidí escribir sobre ésta característica que ningún otro motor presenta.

Llamativamente la guerra de la orientación a objetos ganó en el campo de los lenguajes de aplicación pero no en las bases de datos, a pesar de ello Postgre implementa varios conceptos del mismo (aunque en un nivel básico) y otros motores no lo hacen, se dedican más bien a desarrollarse como motores relacionales, aunque tampoco ningún motor del mercado cumple con las 12 reglas de Edgar Codd. (Continuar Leyendo sobre Herencia de Tablas en PostgreSQL)

Hace tan sólo dos días atrás se liberó la versión estable de Postgre 9.0 y la misma acarrea encima un montón de mejoras y cambios que para mí serán considerados Hitos en las Bases de Datos Libres.

Entre las features más interesantes están éstas:

• Triggers condicionales
• Triggers por columna
• Hot Standby
• Soporte a Windows 64-bit
• Planes de EXPLAIN en JSON y XML

Hay varios otros, en éste enlace pueden encontrar un pequeño resumen en español de lo que nos ofrecerá la nueva versión: ttp://www.postgresql.org/about/press/presskit90.html.es

En este post me centraré principalmente en los disparadores por columna, que justamente unos días atrás buzzeaba con Juan Cuevas si era posible hacerlo, para sorpresa nuestra ahora sí y es el único motor de BBDD que lo está implementando a la fecha. (Continuar Leyendo sobre Como crear triggers a nivel de columnas con PostgreSQL)

Postgre al contrario que MySQL, en su configuración por defecto cierra las escucha de conexiones a todas la IP excepto la local (127.0.0.1 o localhost), a veces puede ser un poco engorroso esto, especialmente si estamos trabajando con base de datos de desarrollo o pruebas. (Continuar Leyendo sobre Como hacer que PostgreSQL escuche conexiones desde cualquier IP)

He notado que mucha gente busca éste tipo de contenido constantemente, así que decido finiquitar a los motores de base de datos más comunes en un único post, dado que también si lo hago por separado sería muy corto.

Una cosa que me gustaría dejar bien en claro, que en la mayoría de los motores que expondré hay más de un modo de conseguir la fecha y la hora del sistema operativo huésped, pero sólo mostraré la más común.
Vamos a lo práctico y veamos: (Continuar Leyendo sobre Obtener la fecha y hora del sistema desde los motores de base de datos más utilizados)

Esta es la tercer entrega, probablemente será la más corta pero no la última aún. El motivo de su longitud es por que es una clase que se utiliza como medio para crear la flexibilidad y portabilidad de fuentes de datos, en éste caso motores de base de datos.

También daremos por terminada la capa de Acceso a Datos, entonces así no mezclamos el código y será más fácil seguirlo posteriormente. También pertenecerá al namespace AccesoDatos. Lo llamo conexión por que es la clase con las otras capas interactuaran en modo directo.
Para ello creamos un objeto estático de la clase GDatos que instanciará de la clase SqlServer. Creo que ya van captando el rumbo de esto no? si crearamos otra clase por ejemplo Oracle.cs o MySQL.cs, solamente cambiariamos una linea de código, donde el objeto GDatos del tipo GDatos, sea SqlServer, Oracle u otro motor que codifiquemos. Podemos hacerlo con ODBC, OleDB para conexiones genéricas. No les parece grandioso que solo deban tocar parte de una línea de código para portar la App a cualquier otro motor de Base de Datos? (Continuar Leyendo sobre Como programar en n-Capas con C# (Parte 3))

Esto que veremos como hacer, se aplica a cualquier base de datos que soporte el tipo de dato BLOB o equivalente, aunque el ejemplo estará centrado en un motor especifico, el PostgreSQL ya que es uno de los motores que mejor tiempo de respuesta ofrece al trabajar con imágenes, hablo una vez que tenemos más del millon de imagenes, esto que digo está basado en una prueba mía con SQL Server, MySQL y Oracle XE. Por eso podría la mejor opción si necesitamos almacenar muchas imágenes y luego tener la facilidad que buscarlas con rápidez.

En éste ejemplo lo insertaremos desde C# .Net, pero primeramente debe existir la tabla que almacenará la imagen, y su tipo de dato debe ser BLOB (Binary Long, o campo binario largo). Las imagénes necesitamos convertirlas al binario para almacenarlas, veremos como tomar una imagen que está en algún directorio y lo almacenamos, también incluye el método para volver a pasarla a imágen por si necesitamos volver a visualizarla, pero (Continuar Leyendo sobre Guardar imágenes en la Base de Datos desde C#)

En PostgreSQL —para los usuarios que vienen de otros motores— no existe el concepto de Procedimientos Almacenados o Stored Procedures, simplemente existen las Funciones que hacen el papel de ambas cosas en otros motores más populares.

Otras de sus particularidades en PLPG/SQL es que éstos soportan sobrecarga (como en la orientación a objetos), es decir, pueden existir más de una función con el mismo nombre (a diferencia del resto) y ser diferenciados por la cantidad y tipos de parámetros recibidos. Vale recordar que este motor es sensible a las mayúsculas, cosa que a los que llegan recién les produce varios inconvenientes.

Básicamente lo que veremos en este post, es 3 ejemplos de funciones, los que retornan valores, los que no. Lo escribiremos en plpgsql y sql estándar también. Existen otros factores que debemos considerar, como (Continuar Leyendo sobre Funciones en PostgreSQL)