Bicosyes - since evermore... » Bases de Datos

Backup incremental de tu base de datos con Git

blaxter — Thu, 09 Jul 2009 19:48:13 +0000

Una forma realmente interesante de realizar backups de tus bases de datos (por ser trivial y muy potente) es usando Git. El proceso es simple y se basa en la realización de los dumps de la base de datos de forma que cada fila de las tablas sea un insert aislado, de esa forma en cada commit solo estaremos salvando las diferencias respecto al último estado (tanto deletes como inserts, como updates).

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 .

Benchmark MySQL vs PostgreSQL vs SQLite vs MSAccess (vs ruby)

blaxter — Fri, 04 Apr 2008 22:19:27 +0000

Por razones que no vienen al caso, me he encontrado hoy con un increíble WTF? usando MySQL (la lista no es corta, pero este era sorprendente, digno de Access o peor). He decidido hacer una comparativa con uno de sus competidores directos, PostgreSQL. Además probaré a intentar resolver el problema usando código en vez de dejar todo el "trabajo" a la base de datos, en concreto lo haré todo en ruby, no por eficiencia sino por comodidad (que sino me canso).

[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).

Bases de Datos Temporales

blaxter — Wed, 17 Jan 2007 14:22:56 +0000

Cuando empecé a investigar sobre las bases de datos temporales me sorprendí por dos motivos, primero porque al final he tenido que recurrir a libros que me han sido mucho más útiles que todo lo que he podido llegar a encontrar en Internet (donde todos los textos eran muy ligeros o escasos en cuanto a profundización en la materia), y segundo por la complejidad del tema, puesto que en realidad lo elegí porque parecía simple, error, craso error.

Antes he hecho la presentación y, en conclusión, me podría apostar un bote de palomitas a que nadie se ha enterado de lo que en realidad es una base de datos temporal, al menos, no el profesor, pues por las preguntas y afirmaciones que ha hecho al final, eso se podía deducir, y dado que la mitad de la gente se dedicaba a hablar con los demás, o pensar en maneras de hacerme callar lenta y dolorosamente, creo que ganaría ese bote de palomitas

Como he dicho antes, encontré muy poco material sobre el tema, no hablemos ya en castellano. Así que voy a dejar aquí colgada la presentación, la cual intenté hacerla algo así como unos mini-apuntes que pudiesen tener contenido completo por ellos mismos. Y además un par de pdf's sobre TSQL2, la especificación y un ejemplo práctico.

BD Temporales (si se te ve muy grande, reduce el tamaño de letra o ponlo a pantalla completa)
TSQL2

Bases de datos: paradigmas y tendencias

blaxter — Tue, 16 Jan 2007 20:16:14 +0000

Debido a una asignatura de la carrera, Bases de datos avanzadas, he tenido que investigar sobre bases de datos temporales. Pero, en verdad, existen muchos tipos de paradigmas y/o tendencias en las BD, muchas de ellas en verdad interrelacionadas entre sí. Voy a intentar hacer un resumen de todas ellas o, al menos, de las que considero más relevantes.

Relacionales, es la base de todo. El modelo más estudiado, comercializado y utilizado. No por ello el mejor, sino que ciertos aspectos (estar en el momento justo, en el lugar indicado) han hecho que así llegue a ser. En definitiva, actualmente hablar de BD es hablar de BD relacionales. Pero todo está cambiando, sino no escribiría este post realmente. Si no sabes qué es el modelo relacional, significa que no sabes que es una BD, por lo que no creo que entiendas el resto de cosas que voy a contar y no se ni para que me lees este tochaco, pero bueno.
Orientadas a objeto, si todas nuestras aplicaciones son con objetos, es tontería querer mantener el modelo relacional por debajo, ¿no?. Existen diferentes ORM que permiten solventar ese inmenso puente entre un modelo de objetos y el modelo relacional, pero si podemos prescindir de él, ¿qué mejor que nuestro SGBD nos entienda directamente y nos guarde objetos directamente?. Hay ciertas cosas bastante llamativas en una BDOO, como que no es necesario tener claves primarias, o las claves ajenas en verdad ahora son referencias. Se podría hablar mucho sobre este tema, pero resumiendo una BDOO son simplemente nuestros objetos hechos persistentes. ¡Capas de persistencia nunca mais!
Activas, una SGBD activo es aquel, que bajo ciertas condiciones, y de manera automática ejecuta acciones anteriormente especificadas, todo ello sin intervención del usuario. Es decir una especie de BD + super-triggers (BD relacional con triggers no es una BD activa). Se puede subdividir en dos modelos que lo constituyen:
- Modelo del conocimiento: especifica las reglas del sistema, en resumen serían tuplas (Evento, Condición, Acción).
- Modelo de ejecución: se encarga de realizar un seguimiento de la situación y de gestionar el comportamiento. Vamos, el jefe que dice qué hacer y cómo.
Deductivas, un SGBD deductivo es aquel que es capaz, a partir de un conjunto de axiomas deductivos y reglas de inferencias que ya posee, deducir hechos. Una especie de BD + lógica (BD + prolog, imagínate sql + prolog, dios que miedo!). Un esquema global podría ser que recibida una consulta concreta, el SGBD deductivo según unas determinadas reglas de inferencia consulta sus datos para obtener una respuesta. Este modelo está muy ligado a las BD Activas, y tienden a converger. Tanto las BD Activas y como las Deductivas podrían englobarse en el área de representación del conocimiento, quizá por ello tiendan a converger.
Temporales, ¡no existen los datos!, adiós datos; bienvenidos los datos temporales (dato + tiempo). Cada dato tendrá información de tiempo válido (cuando ese dato es, o ha sido, válido en el MundoReal) y de tiempo transaccional (cuando ese dato ha estado en la BD). Es decir, ahora no se guarda información, bueno si, pero se guarda junto con su evolución en el tiempo. Todavía es un campo muy ligado a la investigación, a pesar de que son realmente muy interesantes.
Difusas, casi toda la información que manejamos acerca del MundoReal es incompleta, imprecisa y vaga. Las BD Difusas se basan en la lógica difusa que a su vez se basa en álgebra de conjuntos difusa, que viene a ser mayormente que dado un conjunto de elementos se le da un valor a cada elemento, entre 0 y 1, que indica el grado de pertenencia que tiene dicho elemento en ese conjunto. Este modelo se una ampliación de las BD relaciones, y amplía los operadores del álgebra relacional para poder adaptarlos a los nuevos elementos que se definen. Emocionante.
Multimedia, actualmente estamos desbordados por audio, video, imagenes, texto, en definitiva documentos multimedia. Éstos por poder se pueden guardar en campos "Blobs" (binary large objets), pero ya que hacemos modelos de BD para todo lo que se nos ocurre, pues que mejor que una BD Multimedia?. El principal inconveniente está en que una BD tradicional carece de una interfaz de usuario para poder tratar con estos datos multimedia, sin mencionar el problema de la inclusión de metadatos (que se podría solventar, si. Pero serían todo soluciones muy "ad-hoc", eso de ingieneril tiene poco). Las BD Multimedia proponen tres niveles: Un nivel monomedia que trataría con un solo tipo de datos (p.ej. audio), un nivel central que hablaría con todos los niveles inferiores y desde el cual se gestionarían las preguntas y se guardarían los metadatos de todos los elementos de la BD; y un último nivel con una interfaz de usuario para poder manejar cada formato multimedia. Todo esto quizá es muy ambicioso, hay BD actualmente usándose como las BD Documentales que serían un subconjunto de las Multimedia. Quizá sea porque, evidentemente, el texto ha sido lo primero que se ha querido salvar en una BD, tiempo al tiempo...

No son todas las que están, ni están todas las que son. Se podría añadir al conjunto, BD Distribuidas, Federadas, Almacenes de datos (aunque no son BD en el sentido estricto de la palabra), Paralelas, etc... Pero no las considero como un "paradigma" de BD . Por cierto, si has llegado a leer hasta aquí eres macgyver!

Motores de almacenamiento de MySQL

blaxter — Sat, 23 Sep 2006 10:24:16 +0000

Como bien sabrás, querido picacódigo, MySQL es una base de datos relacional de licencia GPL, ésto implica que usa tablas para guardar los datos, visto desde su representación lógica (como lo vemos nosotros, los usuarios). Pero, por dentro, usa un motor de almacenamiento (storage engine) que será el encargado de guardar de verdad los datos a ficheros, según una determinada estrategia. Este motor es totalmente clave a la hora de evaluar la rápidez y las funcionalidades que puede tener el SGBD. MySQL tiene la opción (para cada tabla que se vaya a crear) de establecer explicitamente qué motor usar.

MyISAM, el motor por defecto, permite lo típico, pero no permite transacciones, toda las consultas se realizan con autocommit. Por lo demás no hay mucho que comentar, como curiosidad decir que los BLOB o TEXT pueden ser indices, e incluso un campo que sea indice puede tomar valor NULL. Usa Arboles B internamete para los indices (separado de los datos) y tiene herramientas para chequeo y reparación de tablas.
BLACKHOLE: si tiene un nivel de inglés tan patetico como el mio (o superior) fijo que descubres que hace este motor (blackhole = agujero negro). Sería el equivalente a /dev/null mayormente. Y dirás, ¿y esto para que cojones lo quiero yo?, pues puede llegar a ser útil, pues cuando realizas una transacción con este motor, auque no se guardan los datos, ni te va a devolver nada, si que crea LOG de la sentencia SQL que se "ha ejecutado". El caso típico podría ser establecer un servidor esclavo para que de ese modo guardará el log de lo que pasa en el master
CSV, motor completamente trivial, que guarda cada tabla en un fichero y cada fila de datos es una linea con los datos separados por comas. Queda claro, no?. Para hacer la gracia decir que no soporta indices (imagina buscar en ficheros... coste secuencial! O(n) OMFG!). Este formato sería usado mas bien para crear archivos listos para ser importados por otros programas.
ARCHIVE, el motor almacen almacen, solo soporta INSERT's y SELECT's, es decir un almacen!. Además, siempre que escribes datos se comprimen (con zlib), así que es el motor típico para una base de datos histórica o cuando vamos a tener una cantidad realmente enorme de datos (quizás sea la idonea para GIS?, habría que meditarlo...). Decir que si se realizan muchos SELECT a la vez que se realizan INSERT provocaría que el motor se hiciese la picha un lio, ¿por qué? Porque cuando se hace un INSERT los datos van a un buffer (para no tener que recomprimir, con zlib, para cada puta linea que se inserta supongo...) y éstos datos serán flusheados cuando se realice el SELECT, ahora piensa cientos de INSERT y SELECT en paralelo. Da miedo, eh?
EXAMPLE, este no sirve para nada, jaja. Es solo un ejemplo de motor, para poder mirar su código y crear motores hechos y derechos
FEDERATED, motor nuevo que se incorporó en la versión 5 de MySQL, para poder crear bases de datos federadas, esto significa que estaremos consultando a una bases de datos remota, es decir en nuestro servidor creamos la tabla pero le decimos, oye que esta tabla esta en otro lado, si eso, le preguntas, que fijo que te responde. Este modelo tiene ciertas limitaciones, no permite ALTER's ni transacciones.
MERGE, este es facil, si tienes dos tablas con motor MyISAM y con la misma estructura, al crear una tabla MERGE, juntarás los datos de ambas tablas. Un caso para el cual puede ser útil este motor, podría ser, por ejemplo, diferentes tablas de log en diferentes servidores y te creas en uno de ellos tablas FEDERATED de esas tablas (que serán MyISAM) y entonces creas una tabla de "log_principal" (usando MERGE) que tendrá el log de todos los servidores. arrr marinero.
MEMORY, tablas que se guardan en memoria, es decir, cuando reinicies MySQL, adios datos. No le encuentro ninguna utilidad la verdad, si quieres un almacenamiento temporal, que sentido tiene entonces usar un SGBD? Pues ninguno!.
Berkeley DB (BDB para los friends), una de las bases de datos openSource más famosa y utilizada. El motor es independiente de MySQL, con las ventajas e inconvenientes que esto pueda acarrear. Permite transacciones (COMMIT & ROLLBACK) y solo puede ejecutarse en sistemas operativos soportados (Linux x86 y Windows, si; Mac OS X feo y Linux AMD64/Alpha, no). Como curiosidad decir que su organización de ficheros se basa en solo dos, puesto que utiliza árboles B donde, en cada nodo, están tanto los datos como el índice primario (lo cual implica que será algo más lento a la hora de recorrerlo secuencialmente)
InnoDB, es el motor más avanzado (junto con BDB) en cuanto a opciones y funcionalidad. Permite transacciones seguras (COMMIT y tal) y está orientado a manejar grandes cantidad de datos. Realiza el bloqueo usando como granualidad la fila (BDB lo hace a nivel de página, es decir mayor salvo casos raros de filas enormes) e incluso soporta lecturas consistentes tanto bloqueantes como no bloqueantes.

Como reflexión final decir que los únicos motores que soportar transacciones seguras son BDB e InnoDB. BDB es externo a MySQL (se usa en muchos otros proyectos, como OpenLDAP por ejemplo...) y fue comprado por ORACLE hace unos meses (febrero)... lo mosqueante es que InnoDB también ha sido comprado por ORACLE (antes de la compra de BDB), por lo que así a lo tonto, ORACLE se ha hecho con el control de los únicos motores de MySQL que soportan transacciones, intrigante... y quizás preocupante... Y con esto y un bizcocho...