En el caso concreto de MySQL inicialmente haríamos algo como esto:

$ mkdir mydatabase && cd mydatabase
$ mysqldump --skip-extended-insert > data.sql
$ git init
$ git add data.sql
$ git commit -m "Initial dump of mydatabase"

A partir de entonces podemos automatizar el proceso con un script tan simple como este:

$ cat /usr/bin/git_backup_database
#!/bin/sh
BACKUP_DIRECTORY=$1
DATABASE=$2
 
cd $BACKUP_DIRECTORY && \
mysqldump --skip-extended-insert $DATABASE > data.sql && \
git commit -am "Updating dump `date +%Y_%m_%d__%H_%M`"

Según el volumen de consultas que tenga tu base de datos, te será interesante ponerlo en cron con una frecuencia determina u otra. Adicionalmente sería recomendable ejecutar $ git gc para optimizar el repositorio. Por ejemplo, dos veces al día y una vez a la semana mantenimiento:

0 0 * * * /usr/bin/git_backup_database /path/to/mydatabase mydatabase
0 12 * * * /usr/bin/git_backup_database  /path/to/mydatabase mydatabase
0 1 * * 1 cd /path/to/mydatabase && git gc

Además desde otro equipo nadie te impide hacer un $ git clone ssh://equipo:path/to/mydatabase y tener todo el historial de la base de datos en un plis (bueno eso es relativo, que ocupará lo suyo...) o incluso programar un $ git pull para tener varios backups en distintas maquinas. En definitiva, se abren un sinfín de opciones .

La audiencia que lee Coding Horror y la audiencia que lee Joel On Software están ya entre la elite de los programadores, porque son los tipo de personas que leen cosas con el propósito de mejorar sus cualidades. Y son, así a ojo de buen cubero, 5-10% del total de programadores activos.

No es la gran masa de carne java quienes fueron anteriormente machacateclas en visual basic quienes fueron previamente tiralíneas de cobol quienes están haciendo ahora grandes cantidades de historias extremadamente aburridas internamente en algún lugar. Ah, ¿No te he ofendido?.

Más que elite yo los llamaría decentes. Más sobre el tema aquí.

El libro contiene una 400 páginas, las cuales podrían resumirse y condensarse en una cuarta parte sin problemas, pero el autor continuamente está dando ejemplos y situaciones para plasmar cada concepto que explica. Incluso tenemos implementado, mostrando todo el código, un servicio web completo (gracias en parte a la brevedad de ruby).

¿Qué nos podemos esperar después de leerlo? Comprender de una vez por todas qué es eso del REST, término que asiduamente es malinterpretado y se ha convertido en una de las palabras clave a mencionar para quedar como si entendieses del tema (ya si lo nombras junto con rails, j2ee y [algo] business eres el puto amo).

¿Cuáles son los contenidos? En una primera parte nos habla de los servicios web en general, algo que puede servir para poner en contexto a quien no comprenda o este al tanto de qué y cómo son realmente.

Justo a continuación se nos explica toda la teoría y conceptos relacionados con la arquitectura orientada a recursos (ROA), la base y propósito de todo libro. Luego tenemos una aplicación de estos conceptos, tanto a nivel de diseño como a nivel de implementación. Estos capítulos, totalmente prácticos, sirven para afianzar todo lo anteriormente explicado, pues en pocas páginas el autor diseña e implementa aplicaciones reales (diseña un servicio de mapas, e implementa un agregador tipo del.icio.us). Después tenemos explicaciones concretas de aspectos específicos que podría llegar a tomarse como una referencia para crear servicios web que será realmente útil para cuando volvamos a recurrir al libro en momentos concretos de dudas.

Finalmente se hacen unas comparaciones con los WS-*, para mi sorpresa, sin meterse mucho con ellos (y no será por oportunidades...), pero que después de haber leído todo lo anterior choca bastante como todavía pueden existir cosas tan increíblemente estúpidas y absurdas (¡y que encima todavía se usan!). Para concluir también tendremos el capítulo de rigor sobre ajax y sus implicaciones al usar servicios web rest (pues una aplicación ajax puede tomarse como un mero cliente de un servicio web) y un breve recorrido sobre frameworks existentes que tratan REST (rails en ruby, django en python y restlet en java).

Este es un libro que lo recomiendo encarecidamente a cualquiera que esté o vaya a crear aplicaciones Web (que a día de hoy es como decir a todo el mundo). Incluso para quien crea haber usado exitosamente REST. Pues dada su popularidad creciente, es un término que continuamente se está enseñando y usando erróneamente (me incluyo aquí el primero, y eso que mi pfc iba sobre eso). Ha sido uno de los libros más vendidos del 2007 (de desarrollo de software claro) y no ha recibido pocos elogios que digamos.

Every developer working with the Web needs to read this book

David Heinemeier Hansson, creador de Ruby on Rails

Simplemente, un libro magnifico.

[Actualización 6 abril 2008 @ 19h] Ya puestos, he añadido también SQLite y Microsoft Access.

Presentemos el problema, tenemos dos tablas, A y B, cada una de ellas tiene una clave primaria compuesta por dos campos. Queremos averiguar las tuplas de la primera tabla que tienen como valor en uno de sus campos, valores que no se encuentran en ninguna tupla de la segunda tabla. Es decir una resta simplemente. Poniéndolo decentemente sería tal que:

• Tablas:
  • A(id, otro_id)
  • B(id, otro_id)
• Objetivo: tuplas de A para las cuales no existe ningún elemento en B cuyo valor del campo otro_id sea igual al campo otro_id de A
  • Formalmente: x ɛ A. ∀y ɛ B y.otro_id != x.otro_id
  • SQL: Lo más intuitivo y simple sería

    SELECT * FROM A WHERE A.otro_id NOT IN (SELECT B.otro_id FROM B)

    o usando LEFT JOINs también es simple expresarlo

    SELECT * FROM A LEFT JOIN B USING (otro_id) WHERE B.otro_id IS NULL

Creo que es algo bastante evidente y simple de entender. Aplicado al MundoReal® puede surgir bastantes veces, no es que estemos antes un tipo de consulta retorcida ni nada por el estilo. Habría que resaltar que estamos usando parte de la clave primaria, en ambas tablas involucradas, por lo que en principio la intuición y nuestros conocimientos de bases de datos relaciones nos sugieren que esto va a ir más rápido que el correcaminos.

¿Cómo resolverías esta consulta?, No me hagas pensar, veamos qué nos dice Postgre:

foo=# EXPLAIN SELECT * FROM A WHERE A.otro_id NOT IN (SELECT B.otro_id FROM B);
                          QUERY PLAN
 Seq Scan ON a  (cost=189.91..379.84 rows=4877 width=24)
   Filter: (NOT (hashed subplan))
   SubPlan
     ->  Seq Scan ON b  (cost=0.00..165.53 rows=9753 width=12)
 

Parece buen plan, primero hará un hash de los valores que se le indican en B, le da un coste de menos de 2 décimas (son milésimas los valores) y calcula que devolverá 9753 columnas (que son todas las que hay), luego dice que filtrará todos los de A que no se encuentren en ese hash. Es lo que le hemos pedido, correcto. A este segundo paso le da una estimación de menos de 2 décimas también, y cree que saldrán 4877 resutlados (esto son todo estimaciones, postgre ahora mismo no ha ejecutado nada, solo nos cuenta su vida).

MySQL es un poco más tímido y no da tanto detalle, pero también podemos pedir que nos explique qué va a hacer:

mysql> EXPLAIN SELECT * FROM A WHERE A.otro_id NOT IN (SELECT B.otro_id FROM B) \G
*************************** 1. row ***************************
           id: 1
  select_type: PRIMARY
        table: A
         type: index
possible_keys: NULL
          key: PRIMARY
      key_len: 178
          ref: NULL
         rows: 9754
        Extra: USING WHERE; USING index
*************************** 2. row ***************************
           id: 2
  select_type: DEPENDENT SUBQUERY
        table: B
         type: index
possible_keys: NULL
          key: PRIMARY
      key_len: 178
          ref: NULL
         rows: 9753
        Extra: USING WHERE; USING index

Básicamente dice que si, que va a usar clave primaria para ambas partes y punto. ¡Qué sabiduría!.

Ok, pues vamos a comparar. Podía simplemente ejecutar la consulta y santas pascuas, pero como me apetece comparar también cual es el coste a realizar trabajo de la base de datos vía código, he hecho un pequeño script en ruby, usando ActiveRecord para manejar las conexiones a la base de datos de forma simple. El código entero lo pongo targzeado al final, ahora pongo aquí la parte que interesa:

Benchmark.bmbm{ |b|
   # uno! El brikindans!, digo consulta en MySQL "normal" con el NOT IN
   b.report("(1) Consulta en MySQL") do
      execute_with MySQL::A, :normal
   end
   # La misma que en (1) pero con PostgreSQL
   b.report("(2) Consulta en PostgreSQL") do
      execute_with PostgreSQL::A, :normal
   end
   # La misma que en (1) pero con SQLite3
   b.report("(3) Consulta en SQLite3") do
      execute_with Sqlite3::A, :normal
   end
   # Consulta con MySQL pero esta vez usando LEFT JOIN
   b.report("(4) Consulta en MySQL (LEFT JOIN)") do
      execute_with MySQL::A, :left_join
   end
   # La misma que en (4) pero con PostgreSQL
   b.report("(5) Consulta en PostgreSQL (LEFT JOIN)") do
      execute_with PostgreSQL::A, :left_join
   end
   # La misma que en (4) pero con SQLite3
   b.report("(6) Consulta en SQLite3 (LEFT JOIN)") do
      execute_with Sqlite3::A, :left_join
   end
   # Hacemos el proceso en código de forma penosa, con un coste Ɵ(n^2)
   b.report("(7) Consulta en código (noob mode)") do
      as = MySQL::A.find :all
      bs = MySQL::B.find(:all).map{|i| i.otro_id }
      as.select{|i| !bs.include?(i.otro_id) }.size
   end
   # Hacemos el proceso en código pero de forma decente, restando conjuntos
   b.report("(8) Consulta en código (MySQL)") do
      (MySQL::A.find(:all).map{|i| i.otro_id } -
       MySQL::B.find(:all).map{|i| i.otro_id }).size
   end
   # La misma que en (8) pero con PostgreSQL
   b.report("(9) Consulta en código (PostgreSQL)") do
      (PostgreSQL::A.find(:all).map{|i| i.otro_id } -
       PostgreSQL::B.find(:all).map{|i| i.otro_id }).size
   end
   # La misma que en (8) pero con SQLite3
   b.report("(10) Consulta en código (SQLite3)") do
      (Sqlite3::A.find(:all).map{|i| i.otro_id } -
       Sqlite3::B.find(:all).map{|i| i.otro_id }).size
   end
}

He aquí los resultados en mi pc, con MySQL 5.0.45, PostgreSQL 8.2.7 y SQLite 3.4.2 (sin tunear ninguna, tal y cual vienen en Ubuntu 7.10) y unos 10k registros en cada tabla.

$ ./mysqlVsPostgresqlVsSQLite3.rb
Rehearsal --------------------------------------------------------------------------
(1) Consulta en MySQL                    0.020000   0.000000   0.020000 ( 54.567416)
(2) Consulta en PostgreSQL               0.000000   0.000000   0.000000 (  0.100255)
(3) Consulta en SQLite3                  0.180000   0.030000   0.210000 (  0.295534)
(4) Consulta en MySQL (LEFT JOIN)        0.000000   0.000000   0.000000 ( 54.656340)
(5) Consulta en PostgreSQL (LEFT JOIN)   0.000000   0.000000   0.000000 (  0.080631)
(6) Consulta en SQLite3 (LEFT JOIN)     47.980000   0.360000  48.340000 ( 54.249483)
(7) Consulta en código (noob mode)      21.660000   0.200000  21.860000 ( 30.060858)
(8) Consulta en código (MySQL)           0.520000   0.040000   0.560000 (  0.696692)
(9) Consulta en código (PostgreSQL)      0.960000   0.060000   1.020000 (  1.203388)
(10) Consulta en código (SQLite3)        3.410000   0.190000   3.600000 (  4.141494)
---------------------------------------------------------------- total: 75.610000sec
 
                                             user     system      total        real
(1) Consulta en MySQL                    0.160000   0.010000   0.170000 (  0.200753)
(2) Consulta en PostgreSQL               0.000000   0.000000   0.000000 (  0.027388)
(3) Consulta en SQLite3                  0.140000   0.010000   0.150000 (  0.148729)
(4) Consulta en MySQL (LEFT JOIN)        0.010000   0.000000   0.010000 (  0.000826)
(5) Consulta en PostgreSQL (LEFT JOIN)   0.000000   0.000000   0.000000 (  0.025892)
(6) Consulta en SQLite3 (LEFT JOIN)     51.810000   0.370000  52.180000 ( 69.148641)
(7) Consulta en código (noob mode)      21.340000   0.200000  21.540000 ( 24.971090)
(8) Consulta en código (MySQL)           0.420000   0.010000   0.430000 (  0.503471)
(9) Consulta en código (PostgreSQL)      0.970000   0.070000   1.040000 (  2.188352)
(10) Consulta en código (SQLite3)        3.170000   0.120000   3.290000 (  3.581979)

Adicionalmente he hecho también la prueba usando Microsoft Access 2003, gracias a este connector (que lo he usado para cargar todos los datos). No lo he incluido en las pruebas porque solo funciona bajo Windows, así que he ejecutado las consulta a mano. La primera de ellas le cuesta unos 200 seg aproximadamente mientras que el left join lo ejecuta casi al instante, no más de 0.25 segundos.

Mirando entonces todos los resultados, podemos observar como a MySQL le cuesta dos veces más que la ineficiente consulta con código y 700 veces más que a Postgre. Curioso, oye. En la segunda pasada MySQL ha cacheado el resultado (pero si haces otras consultas y volvemos a hacer ésta, tardaría de nuevo su tiempo "normal") y es bastante más rápido.

En resumen se podría decir que es totalmente inaceptable (al menos para esta simple consulta de dos tablas) usar:

• MySQL (en cualquier caso)
• SQLite usando LEFT JOINs (pero funciona perfectamente con subconsulta)
• MS Access usando subconsulta (pero funciona perfectamente con LEFT JOINs)
• Hacer el trabajo en código de forma estúpida (es lo que tiene)

Por lo tanto, según mi propia interpretación, diría que nos quedan solo tres opciones (si consideramos únicamente estas 4 opciones como base de datos a usar) :

• Usar PostgreSQL
• Usar la base de datos 'X' para un X distinto a MySQL y probar nuestras consultas para ver si le gustan o no al SGBD
• Usar la base de datos 'X', para un X cualquiera, emplear consultas triviales y filtrar en código de forma decente. (opción poco viable para entornos reales cuando tengamos millones de registros y no solo 10 mil)

Y hasta aquí todo, que cada uno saque sus propias conclusiones. No voy a decir que MySQL es una puta mierda, o que PostgreSQL suele ser más lento que el caballo del malo, a decir verdad lo que si que diré es que los benchmark siempre son muy limitados y comparan cosas en un ámbito restringido y controlado, por lo que no sirven para nada, así que no sé para qué narices he escrito todo esto, a decir verdad no sé ni para que estás leyéndolo, pero allá tú.

El código, los dump para postgre y mysql listos para ser cargados en sus respectivas bases de datos, la base de datos en access y la base de datos de sqlite3 los dejó en este fichero por si quieres jugar un rato. Se requiere (aparte de las base de datos obviamente) active record y composite primary keys (ambos instalables como gemas, gem install composite_primary_keys, por ejemplo).

Joel Spolsky

• Es una ciencia (David Gries, 1981)
• Es un arte (Donald Knuth, 1998)
• Es un proceso (Watts Humphrey, 1989)
• Es como tener un coche, siempre tienes que arreglar cosas (P.J. Plauger, 1993)
• Es como conducir un coche, siempre tienes que ir haciendo pequeñas correcciones (Kent Beck, 2000)
• Es un juego (Alistair Cockburn, 2002)
• Es como un bazar (Eric Raymond, 2000)
• Es como la jardinería (Dave Thomas & Andy Hunt, 1999)
• Es como rodar Blancanieves y los siete enanitos (Paul Heckel, 1994)
• Es como cazar hombres lobo o ahogarse con dinosaurios en una hoyo de alquitrán (Fred Brooks, 1995)
• Es como construir un edificio (la mitad de la industria, 19xx)

Posiblemente muchos tengan parte de razón, aunque con la última comparación es con la que estoy totalmente en desacuerdo. Si tuviese que quedarme con una, escogería la de la jardinería. Queda muy cursi, pero es la realidad.

En definitiva, diría que el desarrollo de software es como crear/cuidar un jardín atestado de fauna (incluidos hombres lobo y dinosaurios) que evoluciona según las leyes darwinianas a un ritmo diez millones más rápido del normal (menos los dinosaurios, que están en huelga) y el cual es visitado por turistas españoles que les gusta crear hogueras y practicar sexo al aire libre, a la holandesa.