Un compañero de trabajo que es un crack en temas de optimización de bases de datos me ha pasado la siguiente información. Cuando hacemos una consulta con un LIMIT x, y sobre una tabla con millones de registros, a medida que x aumenta, la consulta se va haciendo cada vez más lenta. Veamos un ejemplo:

SELECT version FROM car LIMIT 300,100; (100 results, 0.01 sec)

SELECT version FROM car LIMIT 3000000,100; (100 results, 2.5 sec)

Si además agregamos un par de JOINS a esta consulta, la complicamos un poco y le añadimos un ORDER BY, los problemas de rendimiento pueden llegar a causar un colapso en la base de datos.

¿Por qué pasa esto?

Para determinar el primer valor que tiene que seleccionar, MySQL debe recorrer desde el primer registro e ir contando hasta llegar al 300, a partir de ahí, cogerá 100. Obviamente, a medida que el valor de X va aumentando, la búsqueda del primer elemento es más lenta y como podemos ver en el ejemplo de arriba, llega a tardar 2,5 segundos en recorrer 3.000.000 de registros.

¿Cómo lo podemos solucionar?

Mi compañero propone hacer la búsqueda acotando a partir de primary key de la tabla, de este modo, al ser un campo indexado la búsqueda es realmente eficiente y nos evitamos cargar la máquina:

SELECT version FROM car WHERE id_car BETWEEN 3000000 AND 3000100; (~100 results, 0.01 sec)

Esta solución no nos sería válida a la hora de construir un paginador, porque en el caso de tener vehículos desactivados u eliminados, unas páginas contendrían 100 vehículos, otras quizá 74… sin embargo, si por ejemplo construimos un script que se recorra toda la tabla car esta es una buena manera de realizar la búsqueda.

Symfony integra Propel ORM por defecto, sin embargo, Doctrine está ganando puntos sobre su rival.

La principal ventaja de cada uno de ellos es:

Propel: Está completamente integrado con Symfony y decenas de plugins sólo funcionan para Propel.

Doctrine: Tiene muy buen rendimiento en ejecución y una forma muy concisa al escribir consultas complejas.

Si te has decidido a utilizar Doctrine en lugar de Propel y no sabes como integrarlo con Symfony, aquí te dejo los pasos para activarlo.

1. Lo primero que deberemos hacer es habilitar sfDoctrinePlugin y deshabilitar sfPropelPlugin, esto lo haremos editando el archivo config/ProjectConfiguration.class.php :

   public function setup()
   {
     $this->enablePlugins(array('sfDoctrinePlugin'));
     $this->disablePlugins(array('sfPropelPlugin'));
   }
   

   o si lo prefieres, puedes habilitar todos los plugins por defecto excepto los que no te interesen:

   public function setup()
   {
     $this->enableAllPluginsExcept(array('sfPropelPlugin'));
   }
   

2. Activado Doctrine, borraremos la caché para asegurarnos que se cargan nuestros cambios:
   symfony cc
3. Crearemos una carpeta doctrine dentro de config que contendrá nuestro archivo schema.yml y listo, ya tenemos a Symfony funcionando con Doctrine
4. Ahora sólo queda abrir el archivo config/databases.yml y cambiar “propel” por “doctrine” (respetando mayúsculas y minúsculas) y eliminar la linea “classname:  PropelPDO“.

Recordemos que a partir de ahora, deberemos utilizar la sintaxis Doctrine, tanto en nuestra definición del schema como en el modelo de nuestra aplicación. Si son tus primeros pasos con Doctrine, puedes ver su documentación original aquí.

Qué es un ORM?

Un ORM o (Object Relation Mapper) es una técnica de programación que nos permite convertir datos entre el sistema de tipos utilizado en un lenguaje de programación orientado a objetos y el utilizado en una base de datos relacional, es decir, las tablas de nuestra base de datos pasan a ser clases y los registros objetos que podemos manejar con facilidad.

Utilizar un ORM tiene una serie de ventajas que nos facilitan enormemente tareas comúnes y de mantenimiento:

1. Reutilización: La principal ventaja que aporta un ORM es la reutilización permitiendo llamar a los métodos de un objeto de datos desde distintas partes de la aplicación e incluso desde diferentes aplicaciones.
2. Encapsulación: La capa ORM encapsula la lógica de los datos pudiendo hacer cambios que afectan a toda la aplicación únicamente modificando una función.
3. Portabilidad: Utilizar una capa de abstracción nos permite cambiar en mitad de un proyecto de una base de datos MySQL a una Oracle sin ningún tipo de complicación. Esto es debido a que no utilizamos una sintaxis MySQL, Oracle o SQLite para acceder a nuestro modelo, sino una sintaxis propia del ORM utilizado que es capaz de traducir a diferentes tipos de bases de datos.
4. Seguridad: Los ORM suelen implementar mecanísmos de seguridad que protegen nuestra aplicación de los ataques más comúnes como SQL Injections.
5. Mantenimiento del código: Gracias a la correcta ordenación de la capa de datos, modificar y mantener nuestro código es una tarea sencilla.

Qué es Doctrine?

Según la documentación oficial, Doctrine es un ORM para PHP 5.2.3 y posterior. Además de todas las ventajas que conlleva un ORM, uno de sus puntos fuertes es su lenguaje DQL (Doctrine Query Language) inspirado en el HQL de Hibernate.

Cuando trabajamos con Doctrine, necesitamos informar a su motor interno de cual es el modelo de nuestra aplicación, para ello podemos hacer ingeniería inversa de nuestra base de datos existente, o si empezamos la aplicación desde 0, crear el modelo en la sintaxis específica que nos propone Doctrine y luego generar toda la base de datos.

Para crear el modelo, doctrine nos da dos alternativas, hacer una clase por tabla e indicarle mediante PHP el tipo de datos que almacenaremos en él, un ejemplo:

// models/generated/BaseUser.php

class User extends BaseUser
{
    public function setTableDefinition()
    {
        $this->hasColumn('username', 'string', 255, array('default' => 'default username'));
        $this->hasColumn('name', 'string', 255, array('default' => 'default name'));
        $this->hasColumn('age', 'integer', 4, array('unsigned' => true));
        // ...
    }

    // ...
}

O crear un esquema en formato YAML (schema.yml) similar a XML, pero bastante más legible. El equivalente al ejemplo anterior en YAML sería:

# schema.yml

# ...
User:
# ...
  columns:
    username:
      type: string(255)
      default: default username
    name:
      type: string(255)
      default: default name
    age:
      type: integer(4)
      unsigned: true
    # ...

Además de definir los campos de cada tabla, también le indicamos las relaciones que tienen con las otras tablas y su tipo (many-to-many, one-to-many, one-to-one…), lo que deja perfectamente estructurada nuestro modelo de datos y su manera de acceder a los valores.

Más adelante seguiré escribiendo sobre las ventajas de Doctrine y añadiendo ejemplos que considere interesantes y/o útiles.

DBDesigner4 es una aplicación gratuita que integra diseño de bases de datos, modelado, creación y mantenimiento en un entorno único.

Instalar DBDesigner4 en Ubuntu y hacer que funcione es relativamente fácil, el problema viene cuando quieres hacer conexiones con la base de datos para hacer, por ejemplo, ingeniería inversa y obtener el modelo gráfico de las tablas.

Para que esto no nos suceda, aquí os dejo los pasos a seguir para que os funcione en vuestra Ubuntu a la primera.

1. Descargarnos las librerias que vamos a necesitar y el programa:

   cd /opt

   wget http://www.silcom.com.pe/soft/xlibs_6.8.2-77_all.deb

   wget http://www.silcom.com.pe/soft/kylixlibs3-borqt_3.0-1_i386.deb

   wget http://downloads.mysql.com/DBDesigner4/DBDesigner4.0.5.4.tar.gz

   wget http://crlab.com/dbx/dbxmda.tar.gz

2. Instalamos...

   sudo apt-get install xkeyboard-config

   sudo dpkg -i xlibs_6.8.2-77_all.deb

   sudo dpkg -i kylixlibs3-borqt_3.0-1_i386.deb

   sudo tar xvfz DBDesigner4.0.5.4.tar.gz

   sudo tar xvfz dbxmda.tar.gz

   sudo mv DbxMda/libsqlmda.so.3.20 /usr/lib/

   sudo ldconfig

3. Hacemos unos cuantos enlaces simbólicos:

   sudo ln -s /usr/lib/kylix3/libborqt-6.9-qt2.3.so /usr/lib/libborqt-6.9-qt2.3.so

   sudo ldconfig

   sudo ln -s /usr/lib/kylix3/libborqt-6.9.0-qt2.3.so /lib/libborqt-6.9-qt2.3.so

4. Por último, sólo nos queda iniciar el programa

   /opt/DBDesigner4/DBDesigner4 &

Si todo ha ido bien, el programa iniciará normalmente mostrándonos el entorno de modelado de base de datos. El siguiente paso será configurar la conexión a base de datos:

1. Click en el menú superior en “Database > Connect to Database” y nos aparecerá una ventana como la que siguie:
2. Click en el botón “New Database Connect” y rellenamos la información:
   • Connection Name: Nombre para la conexión
   • Driver: En nuestro caso, será MySQL pero se pueden elegir varios (Oracle, SQLLite…)
   • Hostname: Donde está localizada la base de datos (generalmente localhost)
   • Database Name: Nombre de la base de datos a la que queremos conectar
   • Username: Nombre de usuario para conectar a dicha base de datos
   • Password: Password de acceso
3. Click en la pestaña “Advanced” y rellenamos los valores como muestra la imágen excepto los campos User Name y Database que deberán contener los de tu conexión:

Ahora ya estás en disposición de conectar el programa con tu base de datos y hacer ingeniería inversa de tus tablas existentes.

Explain es una potente herramienta que MySQL pone a nuestra disposición para orientarnos sobre como está ejecutando una consulta el motor de la base de datos.

Esto nos es de mucha utilidad cuando creamos una consulta nueva, pues nos indica que índices va a utilizar, de que tipo son, como de efectiva será la respuesta al usar esos índices… por lo tanto, podemos detectar rápidamente, por ejemplo, de que nuestra consulta no está bien formada o que nos falta un índice en algún campo concreto.

Si ejecutamos la siguiente consulta:

EXPLAIN SELECT *
FROM user u
INNER JOIN user_profile up ON u.id = up.user_id

Obtendremos una respuesta como esta:

Pero, ¿qué quieren decir estas columnas? ¿qué información nos dan?

1. Table: Nos informa de la tabla a la que nos estamos refiriendo.
2. Type: El tipo de unión que se está usando. Desde la mejor hasta la peor, los tipos de uniones son system, const, eq_ref, ref, range, index, y ALL.
   • System: Tabla con una única fila, por tanto, la respuesta es inmediata.
   • Const: En la tabla coincide una única fila con los criterios indicados. Al sólo haber una fila, el optimizador toma este valor como constante, por este motivo este tipo de tablas son muy rápidas.
   • Eq_ref: Una fila de la tabla 1 será leída por cada combinación de filas de la tabla 2. Este tipo es usado cuando todas las partes de un índice se usan en la consulta y el índice es UNIQUE o PRIMARY KEY.
   • Ref: Todas las filas con valores en el índice que coincidan serán leídos desde esta tabla por cada combinación de filas de las tablas previas. Similar a eq_ref, pero usado cuando usa sólo un prefijo más a la izquierda de la clave o si la clave no es UNIQUE o PRIMARY KEY. Si la clave que es usada coincide sólo con pocas filas, esta union es buena.
   • Range: Sólo serán recuperadas las filas que estén en un rango dado, usando un índice para seleccionar las filas. La columna key indica cual índice es usado, y el valor key_len contiene la parte más grande de la clave que fue usada. La columna ref será NULL para este tipo.
   • Index: Escaneo completo de la tabla para cada combinación de filas de las tablas previas, revisando únicamente el índice.
   • ALL: Escaneo completo de la tabla para cada combinación de filas. Es el peor caso ya que revisará todas las filas para cada combinación.
3. Possible_keys: Posibles indices que utilizará la consulta.
4. Key: Índice utilizado para ejecutar la consulta. Si indica el valor NULL, no se ha escogido ningún índice.
5. Key_len: Cuanto más pequeño sea este valor, más rápida será la consulta, pues nos indica la longitud del índice usado.
6. Ref: Las columnas del índice que se está usando, o una constante si esta es posible.
7. Rows: Número de filas que MySQL debe analizar para devolver los datos solicitados.
8. Extra: Información complementaria sobre como MySQL ejecutará la consulta. Los posibles valores en este campo pueden ser:
   • Distinct: MySQL ha encontrado una fila coincidente con los filtros indicados y no necesita seguir analizando.
   • Not exists: MySQL fue capaz de hacer una optimización LEFT JOIN sobre la consulta y no examinará más filas en la tabla para la combinación de filas previa después de que encuentre una fila que coincida con el criterio LEFT JOIN.
   • Range checked for each record: No se encontró un índice válido. Para cada combinación de filas se hará un chequeo para determinar que indice utilizar y en caso de encontrar alguno válido, lo utilizará.
   • Using filesort: Este valor indica que MySQL necesita hacer un paso extra para encontrar la forma de ordenar las filas. Este tipo de consultas debe ser optimizada.
   • Using index: Recupera la información solicitada utilizando únicamente la información del índice. Esto sucede cuando todas las columnas requeridas forman parte del índice.
   • Using temporary: Para resolver esta consulta, MySQL creará una tabla temporal. Uno de los casos típicos en los que devuelve este valor es cuando usamos un ORDER BY sobre un conjunto de columnas diferentes a las indicadas en la clausula GROUP BY. Este tipo de consultas debe ser optimizada.
   • Where used: Se usará una clausula WHERE para determinar que filas serán comparadas con otra tabla. Si no deseamos regresar todas las filas desde la tabla, y el join es del tipo ALL o index, es muy probable que hayamos escrito algo mal en la consulta.

   Una respuesta en este campo del tipo “Using filesort” o “Using temporary” es susceptible de ser una consulta a optimizar.

Si analizamos la consulta ejecutada anteriormente,vemos que para la tabla con alias ‘up’ está utilizando el tipo de unión `ALL` debido a que no existe ningun filtro en la clausula WHERE (en este caso, es normal ya que queremos devolver todos los valores). Se podría utilizar el índice existente `user_id_idx` pero al no haber ningún filtro, no es necesario usarlo. Para devolver esta consulta MySQL analizará 13 filas.

La segunda fila hace referencia a la tabla con alias ‘u’. Utiliza un tipo de unión `eq_ref` ya que devolverá una fila para cada fila de la tabla `up` pudiendo usar y usando el índice primario de la tabla que tiene una longitud de 4 (muy pequeño). Se está utilizando la columna `user_id` del índice de la tabla `up` y de la base de datos `futbol` analizando una única fila para cada fila de la tabla contigua.

Todos los valores son correctos y podemos asegurar que esta consulta está optimizada!!

Supongamos un escenario real de producción en el que tenemos dos servidores. Una de las máquinas contiene un servidor http y una base de datos MySQL que usamos para abserver el tráfico web; la otra la utilizamos para otras tareas necesarias. Sería magnífico poder utilizar la segunda máquina como backup de nuestro MySQL por si hay algún problema grave en la primera ¿no? En este artículo os explico como hacerlo.

La replicación en MySQL funciona de la siguiente manera, el servidor maestro escribe todas las actualizaciones en un fichero de log binario, y mantiene un índice de los ficheros para rastrear las rotaciones de logs. A su vez, el servidor esclavo, que mantiene una conexión abierta contínua con el maestro, es informado cuando sucede algún cambio en el log binario del maestro, y ejecutan estos cambios en sus tablas.

Configuración de la replica asíncrona unidireccional

1) Localizaremos el fichero de configuración de MySQL de la máquina que hará de maestro. Generalmente lo podemos encontrar en la ruta /etc/mysql/my.cnf y descomentamos las líneas:

log_bin=/var/log/mysql/mysql-bin.log
server-id = 1

Buscamos la misma línea en el servidor que hará las veces de esclavo y descomentamos la línea log_bin y server-id modificando el valor a uno diferente del de master:

log_bin=/var/log/mysql/mysql-bin.log
server-id = 2

Ahora podemos arrancar los dos servidores MySQL para empezar a enseñarles a replicar.

2) Una vez arrancados ambos servidores, nos ponemos en el que hará de master y creamos la base de datos y el volcado de los datos en las tablas. En mi caso haré una importación de un fichero sql:

mysql -u [DBUSER-MASTER] -p -e "CREATE DATABASE `myBaseDeDatos`"
mysql -u [DBUSER-MASTER] -p myBaseDeDatos < myBaseDeDatos.sql

3) Ahora crearemos una cuenta de usuario con permisos de replicación, para autorizar, en el servidor maestro, al nuevo usuario a realizar replicas:

mysql> GRANT REPLICATION SLAVE ON *.* TO '[DBUSER-REPLICATOR]'@'[IP-SERVER-SLAVE]' IDENTIFIED BY '[DBPASS-REPLICATOR]';
mysql> flush privileges;
mysql> exit


4) Finalmente, consultamos el nombre del archivo de log binario y la posición de compensación, datos necesarios para configurar el esclavo:

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000    | 103      |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

5) Una vez hecho esto, volcaremos la base de datos en el servidor esclavo tal y como hicimos con el maestro. Ejecutaré el mismo archivo sql:

mysql -u [DBUSER-SLAVE] -p -e "CREATE DATABASE `myBaseDeDatos`"
mysql -u [DBUSER-SLAVE] -p myBaseDeDatos < myBaseDeDatos.sql

6) Y una vez que el esclavo tenga generada la base de datos, lo configuramos para que esté posicionado con respecto al maestro:

mysql> CHANGE MASTER TO MASTER_HOST = '[IP-SERVER-MASTER]';
mysql> CHANGE MASTER TO MASTER_USER = '[DBUSER-REPLICATOR]';
mysql> CHANGE MASTER TO MASTER_PASSWORD = '[DBPASS-REPLICATOR]';
mysql> CHANGE MASTER TO MASTER_LOG_FILE = 'mysql-bin.0001';
mysql> CHANGE MASTER TO MASTER_LOG_POS = 103;
mysql> start slave;

Y con esto ya queda configurado el servidor esclavo y alineado con el master. Desde este momento comenzará la replicación con el maestro.

Para comprobar que realmente está replicando, podemos ejecutar el siguiente comando en el servidor esclavo:

mysql> show slave status

Eso muestra:

*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: [IP-SERVER-MASTER]
Master_User: [DBUSER-REPLICATOR]
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.0001
Read_Master_Log_Pos: 103
Relay_Log_File: esclavo-relay-bin.000001
Relay_Log_Pos: 103
Relay_Master_Log_File: mysql-bin.0001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: myBaseDeDatos
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 103
Relay_Log_Space: 103
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
1 row in set (0.00 sec)

En Read_Master_Log_Pos y Relay_Log_Pos podemos ver que ambos valores están correctamente alineados. La variable Seconds_Behind_Master nos indica el desfase de actualización entre maestro y esclavo, si todo está bien, mostrará un valor 0.

Muchas veces nos encontramos con la necesidad de crear un campo autoincremental en una tabla de nuestra base de datos. Típicamente suele usarse para generar una clave primaria para dicha tabla. Pues bien, la primera vez que nos enfrentamos con esta situación trabajando con Oracle, nos encontraremos con un grave problema que nos puede hacer perder mucho tiempo, puesto que, aunque parezca mentira, no existe ningún tipo de campo autoincremental en Oracle.

La solución es bastante sencilla (aunque no por ello deja de ser incómodo no disponer de un campo de este tipo directamente). Oracle dispone de un tipo de objeto denominado secuencia (SEQUENCE). Una secuencia tiene un valor inicial, un valor máximo y un valor de secuencia que incrementará cada vez que hagamos una llamada a la secuencia.

La estructura para crear una secuencia es la siguiente:

CREATE SEQUENCE sequence_name
MINVALUE value
MAXVALUE value
START WITH value
INCREMENT BY value
CACHE value / NOCACHE;

Donde:

• MINVALUE es el valor mínimo que tendrá la secuencia (usualmente 0 o 1)
• MAXVALUE es el valor máximo que tendrá la secuencia (se puede obviar y por defecto se le asignará 999999999999999999999999999)
• START WITH es el valor con el que empezará la secuencia
• INCREMENT BY es el valor con el que se incrementará la secuencia (usualmente 1, pero podríamos usar 2 para generar solo valores pares por ejemplo [siempre y cuando hubiesemos puesto el campo anterior a 0 o 2 ] )
• CACHE / NOCACHE el uso de CACHE permite indicar cuantos valores queremos que sean guardados en memoria para una acceso más rápido. El inconveniente que tiene es que en caso de una caida del sistema, los valores generados por la secuencia se pierden y quedarian “huecos”.

Una vez creada la secuencia la usaremos llamando a sequence_name.nextval. Por ejemplo:

INSERT INTO mi_tabla (tabla_id, tabla_campo1) VALUES (mi_secuencia.nextval, ‘valor1′);

También podremos acceder al valor de la secuencia en una consulta haciendo la siguiente llamada (hay que tener en cuenta que esta llamada también nos incrementará el contador de la secuencia):

SELECT sequence_name.nextval FROM dual;

Por último veremos como podemos modificar el valor de la secuencia para asignarle uno arbitráriamente. Primero modificaremos la secuencia indicándole que a partir de este momento cada vez que sea llamada incremente su contador en tantas posiciones como la diferencia entre el valor que queremos asignarle (p.ej. si nuestra secuencia tiene valor 327 y queremos asignarle el 450, deberemos incrementar en 123).

ALTER SEQUENCE seq_name INCREMENT BY 123;

Luego haremos una llamada a la secuencia para que se incremente con el nuevo valor:

SELECT seq_name.nextval FROM dual;

Y por último volveremos a alterar la secuencia para que vuelva a incrementar igual que antes (en nuestro ejemplo de uno en uno)

ALTER SEQUENCE seq_name INCREMENT BY 1;

También existe la posibilidad de generar campos autoincrementales creando un trigger que sea llamado antes de la inserción y se encargue de calcular el siguiente valor libre. O haciendo una consulta previa del primer valor libre del campo. Pero son técnicas más engorrosas y que pueden dar lugar a errores y problemas con más facilidad de la expuesta aquí.

Pues bien, otro post provocado por una necesidad del curro… esa necesidad me ha obligado a googlear un ratito y por último, he aquí el resultado.

La cosa está en que me han pasado unos archivos en formato dbf y para poder hacer el tratamiento necesario necesitaba poderlos importar a MySQL. La solucion está en dbf2mysql, programa que de una manera bastante sencilla se encarga de hacer la importación a la base de datos MySQL.

Los flags más importantes que nos ofrece dbf2mysql són los siguientes:

• -h indica server donde conectarse
• -U usuario MySql
• -P password MySql
• -d base de datos donde se insertaran los datos
• -t tabla donde se insertarán los datos
• -c crea la tabla si no existe
• -cc crea la tabla, pero no inserta registros
• -f traduce los nombres de campo a minúsculas
• -n no se agrega ‘NOT NULL’ en las sentencias de creación de tabla
• -o exporta solo los campos listados (Ej. -o field1,field2…)
• -s substituye permite cambiar nombres de campos (Ej. -s oldName1=newName1,oldName1=newName1)
• -i lista de campos a indexar. Genera UN indice por campo (Ej. -i field1,field2…)
• -r quita espacios antes y después de datos alfanuméricos
• -v muestra detalles de la conversión
• -vv muestra más detalles
• -vvv incluye informe de progreso

Los pasos que he siguido para hacer la importacion són:

1) Instalo dbf2mysql, en mi caso desde Ubuntu:

sudo apt-get install dbf2mysql

En cualquier caso, nos podemos bajar el programa para sistemas Unix de Source Forge

2) Creo una base de datos MySQL vacia:

mysql -u [DBUSER] -p -e "CREATE DATABASE `[DBNAME]`"

3) Por último lanzamos el siguiente comando para indicarle que importe el archivo dbf a la base de datos local, en la tabla [DBTABLE] de la base de datos [DBNAME], entrando con el usuario [DBUSER] y el password [DBPASS]. Mediante el flag -c forzamos a que cree la tabla si no existe y con -f le indicamos que traduzca los nombres de los campos a minusculas:

dbf2mysql -h localhost -U [DBUSER] -P [DBPASS] -d [DBNAME] -t [DBTABLE] -c -f /path/to/file/miTabla.dbf

Es importante tener en cuenta que esta importación no tendra en cuenta algunos atributos importantes de la tabla como, por ejemplo, los campos autoincrementales. Si tenemos algun problema de este estilo, es recomendable crear la estructura de la tabla antes de realizar la importación.

Hace algún tiempo que tenía ganas de migrar una base de datos de ISO-8859-1 a UTF-8, pero cuando tienes un proyecto funcionando, hacer un cambio de este estilo es algo delicado y por lo tanto, uno intenta postergarlo. En cualquier caso, finalmente decidí liarme la manta a la cabeza y tirarlo adelante.

Por desgracia, no existe una sentencia SQL que haga algo similar de manera sencilla, sin embargo, podemos conseguirlo utilizando el comando de Linux recode (evolución bastante más inteligente del antiguo iconv), os dejo detallados los pasos que seguí para hacer el cambio:

1) Exportamos la base de datos mediante el comando mysqldump:

mysqldump -u  -p -f --single-transaction --opt -hlocalhost --all-databases | gzip -9 -c > [FICHERO_EXPORTACION_BD]

2) Recodificamos el archivo dump mediante el comando recode:

recode iso-8859-15..utf8 < [FICHERO_EXPORTACION_BD] > [FICHERO_EXPORTACION_BD].utf8

3) Editamos el archivo y reemplazamos “latin1″ por “utf8″

4) Creamos la nueva base de datos con el encoding utf8:

mysql -u [USER] -p [DBNAME] -e "CREATE DATABASE `[DBNAME]` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;"

5) Por último, importamos la base de datos de la siguiente manera:

mysql -u [USER] -p [DBNAME] < [FICHERO_EXPORTACION_BD].utf8

NOTA!! En mi caso concreto, la aplicación PHP seguía mostrando errores al visualizar la información que provenía de base de datos a pesar de haber cambiado convenientemente los metas del html resultante. En mi caso era debido a que la conexión a la base de datos estaba forzada a leer en ISO. Esto lo solventé añadiendo justo después de la conexión:

@mysql_query("SET character_set_results='utf8'");

o si nuestra version de PHP es superior o igual a la 5.2.3, tambien podemos hacer:

@mysql_set_charset("utf8", $link_identifier);