Éstas dos cláusulas hacen prácticamente lo mismo, por eso generan mucha confusión sobre como usar y cuando usarlo aunque sean realmente sencillas de comprender e implementar además de ser más que útiles.
Básicamente ambas validan un valor o más si es o no NULL y lo reemplazan por otro pero tienen sutiles diferencias.
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)
Ver query’s con la cláusula OVER no es muy común, normalmente la mayoría de los programadores o DBA crean sub-query’s para obtener los mismos resultados, lo que en sí no es malo ya que logran visualizar los mismos datos. El problema principal se encuentra en el rendimiento que tiene uno y otro método.
El motor que sea que estés utilizando optimiza el tiempo de ejecución y los bloqueos de las filas cuando se escribe scripts con OVER ya que el mismo trabaja sobre los datos ya obtenidos, en vez de volver a recuperarlos de origen.
La cláusula OVER está definida en el estándar ISO de SQL, (Continuar Leyendo sobre Como utilizar la cláusula OVER [Partition By / Order by] en SQL [Optimización])
Conocer cuando fue la ultima vez que se accedió a una base de datos en SQL Server no es una tarea fácil de resolver, ya que no hay un valor que sirva específicamente para eso, si es que no llevamos un sistema de auditoría a la par.
Otra manera es ver el registro del transaction log de la base de datos, aunque la misma es muy dificil de interpretar, a parte que son funciones de SQL Server no documentadas por Microsoft y para peor de todo están almacenadas en un formato propietario. (Continuar Leyendo sobre Como saber cuando fue el último acceso a una Base de Datos SQL Server)
Es típico encontrarnos con casos en donde alguien se olvido de colocar una clave única en algún lugar y luego tenemos registros con columnas duplicadas — no me refiero precisamente a claves primarias pero también podría aplicar el caso — y necesitamos eliminarlos pero dejar siempre uno de cada valor único, no es muy compleja la lógica a utilizar pero es una pregunta muy frecuente de como realizar esta tarea.
Para comprender bien la operativa a realizar vamos a hacer un ejemplo muy sencillo, creamos una (Continuar Leyendo sobre Eliminar filas duplicadas con SQL de una tabla)
Los SubQuery’s o SubConsultas son herramientas poderosas si las sabemos usar, y son básicamente consultas anidadas en otras consultas la cual devuelve un conjunto de valores. Prácticamente un SubQuery puede ser utilizado en cualquier expresión y cláusula ya sean SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY.
Como el tema de los SubQuery es bastante largo lo iré partiendo en pedazos agrupados por expresión (recomendación de Juan Cuevas), como lo ven en el título ahora veremos los SubQuerys aplicados en la cláusula FROM.
Ya sabemos que la cláusula FROM sirve para identificar las tablas de donde serán proveídos los datos a retornarse, como un SubQuery retorna un conjunto de valores también (Continuar Leyendo sobre SubQuery SQL: cláusula FROM)
Buenas a todos una vez más… hace unos días tuvimos la visita de un grande en tecnologías Microsoft en mi trabajo, y este articulo es básicamente un resumen de algunos de los puntos más resaltantes de las recomendaciones que nos dio, para realizar sobre nuestro servidor actual, y para nuevos servidores que se quieran instalar. Sin más preámbulos, pasemos de pleno a las recomendaciones, a las cuales, les he dado un toque particular para explicarlas 
(Continuar Leyendo sobre Tips para optimizar el rendimiento de SQL Server)
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))
Continuando con la segunda entrega de la programación en n-Capas, (la primera lo pueden ver aqui). Hasta el momento solo creamos una clase abstracta que servirá de padre para las demás implementaciones (1 clase por cada fabricante de motor).
Ahora nos enfocaremos en crear una capa para conectarnos a SQL Server, si llegamos a cambiar de proveedor de base de datos en algún momento, lo único que deberíamos hacer es agregar una clase semejante a ésta con la implementación especifica para éste motor, ni siquiera debemos modificar ésta clase que veremos ahora, el unico cambio (Continuar Leyendo sobre Como programar en n-Capas con C# – SQL Server (Parte 2))
Ultimos Comentados