Instalar Microsoft ODBC 17 para SQL-Server en Ubuntu 17.10

Una entrada rápida ¿Cómo se instala el driver ODBC 17 para SQL-Server de Microsoft en un equipo con Ubuntu? No es algo muy habitual usar SQL-Server en Linux, pero por si os interes la cosa va así:

sudo su 
curl https://packages.microsoft.com/keys/microsoft.asc | apt-key add -

#PARA OTRA VERSIÓN
#CAMBIA EL 17.10 DE LA URL
#POR LO QUE CORRESPONDA
curl https://packages.microsoft.com/config/ubuntu/17.10/prod.list > /etc/apt/sources.list.d/mssql-release.list

exit
sudo apt-get update
sudo ACCEPT_EULA=Y apt-get install msodbcsql
# LO SIGUIENTE ES PARA LOS COMANDOS bcp Y sqlcmd
# ES OPCIONAL PERO MUY RECOMENDABLE
sudo ACCEPT_EULA=Y apt-get install mssql-tools
echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> ~/.bash_profile
echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> ~/.bashrc
source ~/.bashrc
# PARA LOS ENCABEZADOS unixODBC
# ES OPCIONAL, PERO DE NUEVO RECOMENDABLE
sudo apt-get install unixodbc-dev
Anuncios

Trabajar con porcentajes en SQL-Server: evitar conversión a entero.

Me animo a hacer esta entrada porque habla sobre algo simple pero que por un detalle me rompió la cabeza.

Vamos con el caso/ejemplo, tenemos una tabla Precios con tres columnas: descripción, precio y descuento. La primera es de tipo varchar, la segunda del tipo money y la tercera del tipo numeric, ya que almacena el porcentaje que descontamos sobre el precio. En la consulta queremos sacar esos tres campos y un cuarto campo calculado, el importe con el descuento aplicado. Parece que bastaría con una consulta así:

Select 
  Descripcion,
  Precio,
  Descuento
  Precio * (1-Descuento/100) as ImporteConDescuento
from
  Precios

Y ya estaría, ya tenemos nuestro importe con descuento… Pero ejecutas la consulta y ves algo raro ¿los decimales? ¿dónde están? Se está redondeando el cálculo para que devuelva un valor entero. ¿Por qué? Porque al haber operado con dos enteros en el cálculo del porcentaje el motor que realiza la consulta ha convertido el resultado a entero. Sí, así es, si operas con enteros hace una conversión a ese tipo (al menos SQL-Server 2008). Para obtener el resultado correcto tendrías que hacer así la consulta:

Select 
  Descripcion,
  Precio,
  Descuento
  Precio * (1.00-Descuento/100.00) as ImporteConDescuento
from
  Precios

Así que acuérdate de los tipos cuando uses una constante en una operación: si el resultado tiene que ser decimal usa decimales.

SQL-Server. Vistas con índices ¿Cuándo no son recomendables?

Añadir un índice a las vistas en SQL-Server puede ser una buena idea para mejorar la velocidad de lectura en consultas sobre la misma, pero en determinados casos puede no ser recomendable ya que el mantenimiento de estos índices penaliza la velocidad en la inserción, borrado y actualización de datos. Me ha pasado que tras crear una vista con varios índices el funcionamiento de la aplicación empeoraba: ganaba dos segundos en la carga de datos pero perdía casi diez en la inserción.

¿En qué casos NO es recomendable crear índices sobre vistas?

  • Sistemas OLTP con muchas operaciones de escritura.
  • Bases de datos con múltiples actualizaciones.
  • Consultas que no requieran de joins o de funciones de agregado.
  • Consultas con agregación de datos con un alto grado de cardinalidad. (Es decir, que el conjunto de datos que devuelve la vista tenga prácticamente el mismo número de líneas que la tabla indizada)
  • Vistas que tienen conjuntos de resultados que son más grandes que los datos originales en las tablas base.

Aquí os dejo un artículo muy interesante, en inglés, sobre el tema. Ya tiene unos años pero los consejos son igualmente válidos.

SQL-Server: Anti-Join con NOT EXISTS()

Habíamos visto dos técnicas para hacer un anti-join en SQL-Server sin recurrir al NOT IN(): la primera con un left join y comprobando qué campos vienen a nulo y la segunda con el operado EXCEPT. ¿Hay una tercera opción? Sí, la hay: NOT EXISTS(). Como recordaréis ya habíamos visto por aquí que EXISTS() es una función de SLQ-Server muy bien optimizada, y en este caso podemos usarla también.

Vamos a poner un ejemplo: Tenemos la tabla Oficinas y tenemos la tabla Empleados. Las oficinas tienen un campo IdOficina que las identifica, los empleados también tiene un campo IdOficina que nos dicen en qué oficina trabajan. Queremos sacar en una consulta qué oficinas no tienen empleado. Veamos la consulta:

Select 
  o.IdOficina
from 
  Oficinas o
where 
  NOT EXISTS 
    (Select * from Empleados e where e.IdOficina = o.IdOficina)

¿Cual de los tres métodos es mejor? La recomendación es que le pegues un ojo al plan de ejecución para que veas cual tiene un menor coste.

SQL-Server: Hacer un anti-join con EXCEPT

El otro día os comentaba cómo hacer un anti-join en SQL-Server (a decir verdad con un método que valdría para cualquier SGBD), pero me dejé fuera otra forma de hacerlo en SQL-Server: con el operador EXCEPT.

La definción de EXCEPT vendría a ser la siguiente: Devuelve los valores distintos de la consulta situada a la izquierda del operando EXCEPT que no se devuelven desde la consulta derecha.

Vamos con un ejemplo: Tenemos la tabla Productos y tenemos la tabla Ventas, y el campo IdProducto existe en ambas, siendo la clave primaria de la tabla Productos y figurando como clave externa en tabla Ventas. Entonces ¿Podemos con EXCEPT sacar los Id de todos los Productos que no existen en la tabla Ventas? Podemos. Tal que así:

Select IdProducto from Productos
EXCEPT
Select IdProducto from Ventas

Al igual que ocurren con el operador UNION, el operador EXCEPT nos obliga a tener las mismas columnas, con tipos de datos compatibles, en cada una de las consultas.

SQL: cómo hacer un ANTI JOIN

Te habrá pasado más de una vez: necesitas sacar todos los valores de la Tabla1 que no aparezcan en la Tabla2. Es decir, la operación opuesta a un INNER JOIN. En muchos casos vemos que hay quien usa un NOT IN() como solución:

Nota: Asumimos que las tablas están bien formadas y que la Tabla1 se relaciona con la Tabla2 por medio de una clave externa (en el ejemplo será el campo IdClaveExterna en Tabla2 que está relacionado con el campo id de Tabla1)

SELECT * FROM Tabla1 
WHERE Tabla1.id NOT IN (SELECT IdClaveExterna FROM Tabla2)

Y esto está mal. Muy mal. Porque el IN() tiene un rendimiento muy bajo, como hemos visto en el pasado, y su negación pues todavía ofrece uno peor. Entonces ¿cómo lo hacemos? No tenemos una unión que sea ANTI JOIN, pero lo podemos resolver de la siguiente forma ya que tenemos un campo Id en cada tabla para cada fila sirviendo como clave primaria:

SELECT * FROM Tabla1 
LEFT JOIN Tabla2 ON Tabla1.id = Tabla2.idClaveExterna
WHERE Tabla2.id IS NULL

De esta forma cogemos todos los valores de la Tabla1 unidos a la Tabla2 por la clave externa, pero descartando de la consulta aquellos valores que nos devuelvan nulo el valor de la clave primaria de la Tabla2.

SQL-Server: Select * vs Select 1 en una cláusula EXISTS()

Una duda que me asaltó hoy ¿Es más eficiente usar Select * o usar Select 1 en una subconsulta de una cláusula EXISTS?

En principio podríamos pensar que Select 1, al no tener que devolver una lista de columnas,sería mucho más eficiente. Pero si analizamos el plan de ejecución de la consulta vemos que no, que el rendimiento es similar. ¿Por qué?

La propia Microsoft lo explica en esta entrada de sus manuales: SQL-Server no produce ningún dato cuando una consulta está dentro de EXISTS, simplemente evalúa el WHERE de dicha consulta para comprobar si devolvería algo y, según esto se cumpla, devuelve TRUE o FALSE. Por tanto, usar Select * en este caso no empeoraría el rendimiento de la consulta.