otra duda

[Alvaro Herrera]

On Wed, Apr 28, 2004 at 08:31:05PM -0400, Joel A. Iturra wrote:

Joel,

> > Por ej. si tienes tablas InnoDB y tablas
> > MyISAM mezcladas, y en una transaccion haces cambios a ambos tipos de
> > tablas, al hacer ROLLBACK los cambios se deshacen en las tablas InnoDB
> > pero no las MyISAM; el estado es inconsistente al final.  Y cuidado,
> > porque si en la declaracion de una tabla se te olvida poner
> > "type=innodb", la tabla no sera transaccional, no se te avisara de esto,
> > las transacciones se ejecutaran aparentemente con exito pero al hacer
> > rollback no pasa lo que tu esperas ... en resumen puede pasar cualquier
> > cosa.
> 
> pero eso es obvio poh alvaro, si las transacciones estan solo para innodb en 
> mysql, no puedes esperar que funcione en otro tipo de tablas. Osea, si el que 
> esta haciendo la cuestion no tiene clara la diferencia, no es culpa de mysql

Si, para mi y para ti puede ser obvio, pero si quiere llamarse
"transaccional" al menos deberia mandar un mensaje feo o tirar un error
cuando en una transaccion se involucra una tabla no transaccional.  O
derechamente, dado que se supone que el sistema es transaccional, no
deberian existir los tipos de tablas no transaccionales!


> > Idem con la integridad referencial: si tu declaras una tabla con llaves
> > foraneas pero no es InnoDB, nadie te va a informar que la llave foranea
> > no esta siendo validada.
> 
> por eso cuando definas tus tablas, debes asegurarte que todas sean innodb, de 
> lo contrario es como querer que vuele un auto (solo un ejemplo) 

Me acuerdo haber oido que si tenias MySQL compilado sin tablas InnoDB
(versiones antiguas) y creabas una tabla con tipo InnoDB, el motor la
cambiaba a MyISAM y no te daba ninguna indicacion de esto!


> > Ojo con ingresar fechas 31 de febrero; el servidor las acepta y tu no
> > sabes que diablos metio ahi dentro.  Uno podria decir que es culpa de la
> > aplicacion, pero lo cierto es que el sistema debe hacer chequeos.  Idem
> > con numeros demasiado grandes y otras cosas raras.  Trata de calcular
> > 123456789012345678901234567890 % 123; MySQL te dira 58.  Pero la
> > respuesta correcta es 117.  WTF!?  i.e.: no puedes confiar que MySQL te
> > entregue respuestas correctas.
> 
> bugs los tiene cualquiera no ??  y no son medios rebuscados esos ejemplos ??

De partida no son bugs, porque los de MySQL reconocen que estan ahi y no
los reparan (en el manual dice por ahi que los numeros muy grandes son
truncados y nuevamente, el usuario no tiene ningun mensaje de este
hecho)

No me parecen rebuscados en absoluto; si uno quiere datos consistentes,
todos los datos tienen que ser consistentes, no solo los que son
obviamente consistentes.  Es que los gallos para ganar rendimiento sacan
los chequeos de integridad que a mi juicio son basicos (y el de
cualquiera que valore sus datos).


> > (==> no puedes tener cluster _y_ transacciones _y_ rendimiento ...
> > escoge solo una).
> 
> ahi cada uno ve donde le aprieta el zapato, si se puede vivir con eso, cual es 
> el problema ??

No se ... un motor de bases de datos que "inventa" cosas de esta manera
como MySQL no me da ninguna confianza.  Todo es bastante al lote.  En
PostgreSQL hay un esfuerzo constante para que esto no suceda, aunque a
veces se pierda un poco de rendimiento.  El tema de fondo es que lo
importante es entregar respuestas correctas, aunque sea un poco mas
lento.  Si la respuesta es erronea, de que te sirve que te la entreguen
muy rapido?  Para eso mejor generas datos al azar, total igual estan
malos.

> respondiendo la pregunta original, yo diria que "depende".

Yo diria que si los datos son importantes, no depende.  Si es para hacer
un sitio de articulos + comentarios y no importa que se pierdan algunos
de vez en cuando, o que aparezcan datos brujos, entonces puede no
importar ... pero si es el caso, mejor usa SQLite que es aun mas rapido.

> En todo caso concuerdo que si aun no han escogido una db y el asunto a 
> desarrollar es grande (complejo), mejor tirarse por postgresql.

No te quepa duda.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Uno puede defenderse de los ataques; contra los elogios se esta indefenso"