LuAuF » SQL

Exportar una base de datos MDB a SQL (mysql, oracle, sybase, etc.)

Luciano — Tue, 13 Sep 2011 02:00:38 +0000

Recuerdo instantes de mi pasado donde he tenido la necesidad de llevar Bases de Datos MDB, Microsoft Access, a bases de datos MySQL.

Recuerdo por entonces MySQL Migration Toolkit, una herramienta para realizar esta carga requerida. No obstante no era de mi agrado, y lo que buscaba por entonces era simplemente obtener un script SQL con el código DDL y DML necesario para el CREATE de los objetos de la base de datos y los INSERTs de los datos. A esa utilidad, hoy Linuxeando, le encontré el nombre: mdbtools.

MDBtools es un suite de herramientas (mdb-array mdb-header mdb-parsecsv mdb-schema mdb-tables mdb-export mdb-hexdump mdb-prop mdb-sql mdb-ver) que permiten, entre sus funciones, obtener esquema de una base de datos y exportar en SQL los datos de la misma.

Veamos un ejemplo básico y sencillo que consiste en:

Exportar el diseño de la vieja y querida Neptuno.mdb (conocida base de datos distribuida como ejemplo con Microsoft Access) en formato de sentencias de definición de datos SQL.
Obtener el nombre de las tablas de la misma base de datos
Exportar los datos de cada tabla bajo la forma de INSERTs SQL.

$ sudo aptitude install mdbtools

$ mdb-schema Neptuno.mdb mysql> Neptuno_schema.sql #donde mysql se puede reemplazar por otro dialecto: oracle, sybase o postgres.

$ for tabla in `cat Neptuno_tables.txt`; do mdb-export -R \; -I Neptuno.mdb ${tabla}; done> Neptuno_data.sql

$ rm Neptuno_tables.txt

Fácil, sencillo y util... lástima que en mi caso llega tarde, no obstante en conocimiento perdura y nadie puede asegurarme que no me encuentre alguna vieja MDB en mi camino.

Vía: Wikipeando

“Tracear” artesanalmente consultas SQL

Luciano — Tue, 02 Jun 2009 08:00:20 +0000

Lo que leeremos ahora es una solución bastante artesanal para tracear consultas SQL. Cuando leia mis feeds y leí el título de Cómo “tracear” consultas SQL entré inmediatamente debido a que desconocía un método para realizar esta tarea. Lo que suele suceder es que aveces queremos resolver los problemas de una forma prolija y elegante y lo cierto es que la solución puede ser bastante más rudimentaria pero muy ingeniosa.

Muchas veces suele ser tarea común la de consultar en MySQL el slow query log o verificar en tiempo real con un show processlist cual es esa consulta que está volviendo lento al servidor. Conocida la consulta, ¿como se cual es la aplicación que utiliza dicha consulta?. A menos que conozcamos muy bien nuestro sistema, debemos empezar a buscar en nuestros archivos y hacer algunos que otros grep recursivos hasta encontrar con la aplicación culpable de esa consulta lenta.

Esta solución nos evita perder tiempo buscando el fuente que ejecuta la consulta y es tan sencilla como... utilizar comentarios en nuestra consulta. Si! así de fácil y básico como eso, sin dudas muy artesanal, pero efectivo

SELECT /* FILE: procesaDB.c, FUNCTION: getBultos(), LINE 138 */ campo1, campo2 FROM tabla

Vía: Delirios de un Informático

Lineamientos generales para la codificación SQL

Luciano — Sat, 13 Dec 2008 03:00:52 +0000

Pinal Dave, MVP (Most Valuable Professional) en SQL Server, publicó hace un tiempo una guía de "estándares" para la codificación en SQL Server (Parte 1, Parte 2), aunque la mayoría de los lineamientos pueden ser aplicados tranquilamente en cualquier código SQL.

A pesar que los estándares suelen limitarnos mucho y darnos la sensación de perder creatividad en algunos aspectos, son mucho más preferibles que a no tenerlos.

Publico abajo algunas de las reglas mencionadas en el blog de sqlauthority traducidas al español y aplicables a SQL en general (no enfocado directamente en TSQL).

Utilizar la notación de "Pascal" para objetos como tablas, vistas y stored procedures. Es decir, escribir palabras todas juntas separadas por mayusculas. Además, no está mal terminar con "s". Por ejemplo:

UserDetails
Emails

Utiliza un prefijo para todo gran grupo de tablas. Por ejemplo:

Page_UserDetails
Page_Emails

Utiliza las siguientes convenciones para nombras stored procedures, triggers, indices, foreign keys y primary keys.

Stored procedures: sp[__]. Donde acción es un verbo como Get, Delete, Update, Write, Archive, etc. Por ejemplo: spUserAdministration_Page_UpdateEmails

Triggers: TR__. Por ejemplo: TR_Emails_LogEmailChanges

Indices: IX__. Por ejemplo: IX_UserDetails_UserID

Claves primarias: PK_. Por ejemplo: PK_UserDetails

Claves externas: FK__

Evita el uso de SELECT *. Usa nombres de columnas a continuación de la sentencia SELECT.

Indenta las consultas SQL. Por ejemplo:

SELECT Username, Password
FROM UserDetails ud
INNER JOIN Employee e ON e.EmpID = ud.UserID
en vez de:
SELECT Username, Password FROM UserDetails ud INNER JOIN Employee e ON e.EmpID = ud.UserID

Escribe las sentencias SQL en mayúsculas.
Intenta utilizar la primary key en las condiciones de los UPDATEs o DELETEs.
Crea los stored procedures en la misma base de datos donde existe la tabla.
En vez de utilizar un LOOP para insertar datos de una tabla A a una tabla B, intenta usar INSERT INTO... SELECT...
Evita utilizar espacios o palabras reservadas para el nombre de los objetos de la base de datos.
Intenta escribir comentarios en todo stored procedure, trigger o batch sql.
Evita utilizar wildcards al principio de una palabra en una búsqueda con LIKE.
Cuando utilices JOINs, siempre utiliza el nombre de la tabla delante del nombre de la comlumna. Adicionalmente, se puede agregar nombre del servidor, nombre de la base de datos y/o propietario.
Cuando tienes condiciones con varias ramas, utilizar paréntesis puede mejorar la lectura de expresiones complicadas.
Utiliza -- para comentar una línea simple y /* */ para marcar una sección se código comentada.
Analiza todas las consultas y optimizalas. Por ejemplo: SHOWPLAN_ALL en TSQL o EXPLAIN en MySQL.
Utiliza vistas para datos frecuentemente requeridos, con JOINs y/o cáculos complicados.
Evita guarda datos binarios o imágenes en la base de datos. En vez de eso, es preferible guardar el path de donde se almacena la imagen o el archivo en el servidor.
Utiliza siempre la lista de columnas de un INSERT. Esto previene problemas cuando cambie la estructura de la tabla.
Realiza todas las tareas de chequeos de integridad y validaciones de datos por medio de constraints en vez de triggers.
No utilices nombres de columnas en la cláusula ORDER BY, puesto esto puede reducir la legibilidad de la consulta SQL. Por ejemplo:

SELECT UserID, UserName, Password
FROM UserDetails
ORDER BY UserName
en vez de
SELECT UserID, UserName, Password
FROM UserDetails
ORDER BY 2

Puedes diferir de algunas de las reglas antes mencionadas, pero el objetivo no es imponer reglas sino simplemente tener un marco sobre el cual trabajar de manera prolija y ordenada. De hecho, puedes armar tu propio estándar de codificación para tu grupo de trabajo.

Via: ecuador.latindevelopers.net

Usar SQL para generar SQL

Luciano — Thu, 12 Jun 2008 00:49:22 +0000

El principio para la creación de cadenas SQL a partir de SQL consiste, básicamente, en recorrer la metadata (information schema) de una base de datos y armar strings sql a partir de la concatenación strings constantes y del nombre de los objetos (nombre de tablas, nombre de campos, nombre de constraints, etc.) de la base de datos.

Las consultas SQL utilizadas pueden variar en cuanto a los nombres de los campos, tablas involucradas u objetos del sistema de acuerdo al sistema de gestión de base de datos utilizado, pero el funcionamiento es el mismo. El único esfuerzo extra a realizar será investigar el diccionario de datos de cada DBMS.

Los ejemplos mencionados en el artículo original, correspoden a consultas de Oracle, en nuestro caso, veremos ejemplos similares para una base de datos MySQL:




-- Cantidad de filas por tablas

USE information_schema;

SELECT CONCAT('SELECT count(*) FROM ' , table_schema , '.' , table_name , ';') FROM tables;

-- Quitar las foreign key de las tablas

USE information_schema;

SELECT CONCAT('ALTER TABLE ' , table_name , ' DROP FOREIGN KEY ' , constraint_name , ';') FROM table_constraints WHERE constraint_type = 'FOREIGN KEY';

-- Generar un scripts de inserts de una tabla

SELECT CONCAT('INSERT INTO usuarios (id,nombre,apellidos) VALUES ( ' , id , ',"' , nombre , '","' , apellidos , '");') FROM usuarios;

Vía: Micro Codes

Inner, Outer, Natural & Cross JOINs

Luciano — Sat, 31 May 2008 18:13:40 +0000

La intención de esta publicación es hacer un breve resumen de los distintos tipos de JOINs disponibles en SQL y para finalizar, un ejemplo práctico de cada uno de ellos.

INNER JOIN: es el caso de unión interna clásico, combina dos o más tablas descartando todas las filas resultados que no se correspondan en ambas.
LEFT OUTER JOIN (o LEFT JOIN): combina dos tablas con la diferencia que selecciona todas las filas de la primer tabla sin importar tengan o no coincidencia en la segunda. RIGHT OUTER JOIN (o RIGHT OUTER): es la opción inversa a la anterior. En la mayoría de las bases de datos actuales se puede omitir OUTER.
FULL OUTER JOIN: combina los resultados de dos o más tablas, tengan o no coincidencia entre sí.
CROSS JOIN: retorna el producto cartesiano de dos o más tablas, es decir, combina cada fila de una tabla con cada fila de otra tabla. CROSS JOIN no debería llevar la clausula ON.
NATURAL JOIN: Es un caso especial de INNER JOIN que compara por cuenta propia la equivalencia de columnas con el mismo nombre y tipo de dato entre dos o más tablas para hacer la combinación de ambas. Hay que tener especial cuidado con su uso, pues puede producir resultados ambiguos o generar problemas si se añaden, quitan, o renombran las columnas.

A continuación veremos un ejemplo bien comentado, donde se ponen en práctica algunos de los distintos tipos de JOIN. El ejemplo fue escrito para MySQL, pero no deberían ser muchas las líneas a modificar para portar el código a otra base de datos.

Esquema de la base de datos y datos de prueba:




CREATE DATABASE administracion;

USE administracion;
CREATE TABLE empleados (

    id_empleado SMALLINT PRIMARY KEY,

    nombre VARCHAR(64),

    id_funcion INT,

    id_sector INT,

    id_localidad INT

);
CREATE TABLE funciones (

    id_funcion INT PRIMARY KEY,

    nombre VARCHAR(128)

);
CREATE TABLE sectores (

    id_sector INT PRIMARY KEY,

    nombre VARCHAR(128)

);

       

CREATE TABLE localidades (

    id_localidad INT PRIMARY KEY,

    nombre VARCHAR(128)

);
INSERT INTO empleados VALUES ( 1, 'Marcos Aguirre', 1, 1 , 3);

INSERT INTO empleados VALUES ( 2, 'Esteban Quito', 2, 4 , 2);

INSERT INTO empleados VALUES ( 3, 'Daniel Perez', 1, 2 , 1);

INSERT INTO empleados VALUES ( 4, 'Carlos Molina', 1, 1 , 3);

INSERT INTO empleados VALUES ( 5, 'Marcos Aguirre', 4, 1 , 1);
INSERT INTO sectores VALUES ( 1, 'Mantenimiento' );

INSERT INTO sectores VALUES ( 2, 'Ingenieria' );

INSERT INTO sectores VALUES ( 3, 'Costos' );
INSERT INTO funciones VALUES ( 1, 'Programador' );

INSERT INTO funciones VALUES ( 2, 'Analista funcional' );

INSERT INTO funciones VALUES ( 3, 'Administración' );
INSERT INTO localidades VALUES ( 1, 'Maldonado' );

INSERT INTO localidades VALUES ( 2, 'Salto' );

INSERT INTO localidades VALUES ( 3, 'Federación' );

Ejemplos JOIN:




-- INNER JOIN

SELECT   e.nombre, f.nombre, s.nombre, l.nombre

FROM       empleados e

        INNER JOIN funciones    f USING (id_funcion)

        INNER JOIN sectores     s USING (id_sector)

        INNER JOIN localidades  l USING (id_localidad);
-- nombre          nombre       nombre         nombre     

-- --------------  -----------  -------------  -----------

-- Marcos Aguirre  Programador  Mantenimiento  Federación

-- Daniel Perez    Programador  Ingenieria     Maldonado  

-- Carlos Molina   Programador  Mantenimiento  Federación

-- CROSS JOIN:

SELECT   empleados.id_empleado, funciones.id_funcion, sectores.id_sector, localidades.id_localidad

FROM       empleados 

        CROSS JOIN funciones

        CROSS JOIN sectores

        CROSS JOIN localidades
-- No voy a mostrar el resultado pues son bastantes filas (135 filas)

-- empleados CROSS JOIN funciones = 15 filas

-- empleados CROSS JOIN funciones CROSS JOIN sectores = 45 filas

-- empleados CROSS JOIN funciones CROSS JOIN sectores CROSS JOIN localidades= 135 filas

-- LEFT OUTER JOIN (o LEFT JOIN)

SELECT   e.nombre, f.nombre, s.nombre, l.nombre

FROM       empleados e

        LEFT JOIN funciones     f USING (id_funcion)

        LEFT JOIN sectores  s USING (id_sector)

        LEFT JOIN localidades   l USING (id_localidad);
-- nombre          nombre              nombre         nombre     

-- --------------  ------------------  -------------  -----------

-- Marcos Aguirre  Programador         Mantenimiento  Federación

-- Esteban Quito   Analista funcional  (NULL)         Salto      

-- Daniel Perez    Programador         Ingenieria     Maldonado  

-- Carlos Molina   Programador         Mantenimiento  Federación

-- Marcos Aguirre  (NULL)              Mantenimiento  Maldonado  

-- NATURAL JOIN

-- ------------

SELECT   e.nombre,l.nombre

FROM       empleados e

        NATURAL JOIN localidades l;

-- No tenemos resultados, pues la base de datos intenta hacer la combinación utilizando los campos id_localidad y nombre 

-- Les avisé que era peligroso el uso de NATURAL JOIN
-- Para evitar esto, deberiamos cambiar el nombre del campo 'nombre' de la tabla 'localidades'

ALTER TABLE localidades CHANGE nombre nombre_localidad VARCHAR(128);
SELECT   e.nombre,l.nombre_localidad

FROM       empleados e

        NATURAL JOIN localidades l;
-- nombre          nombre_localidad

-- --------------  ----------------

-- Marcos Aguirre  Federación     

-- Esteban Quito   Salto           

-- Daniel Perez    Maldonado       

-- Carlos Molina   Federación     

-- Marcos Aguirre  Maldonado

Múltiple INNER JOIN – MySQL vs MS SQL

Luciano — Mon, 12 May 2008 00:13:20 +0000

MySQL tiene una sintaxis bastante flexible comparada con MS SQL al momento de hacer JOINs. En MySQL puedes hacer un JOIN de dos maneras, sin embargo, sería conveniente hacerlo de la forma de MS SQL de manera de que el código sea más portable.

En MySQL pudes hacer un múltiple JOIN (JOIN entre varias tablas) de la siguiente manera:




SELECT  * 

FROM    tabla1

    INNER JOIN tabla2 ON tabla1.id=tabla2.id

    INNER JOIN tabla3 ON tabla2.id2=tabla3.id2

En esta consulta, los JOINS son ejecutados secuencialmente, primero se hacer el primer JOIN, cuando está listo se hace el siguiente, luego el siguiente y así sucesivamente.

En MS SQL, la sintaxis para el múltiple JOIN necesita hacerse de la siguiente forma (también soportada por MySQL):




SELECT  * 

FROM    tabla1

INNER JOIN 

    (tabla2 INNER JOIN tabla3 ON tabla2.id2=table3.id2) 

    ON tabla1.id=tabla2.id

En esta consulta, los JOINs son ejecutados de adentro hacia afuera. Primero se ejecuta el JOIN entre paréntesis más internos, luego el siguiente fuera de los paréntesis, luego el siguiente y así sucesivamente.

Vía: VXT

Inyección SQL

Luciano — Tue, 08 Apr 2008 03:18:42 +0000

Un poco de humor con SQL Inyection...