Algo de bases de datos en Linux...

[Horst H. von Brand]

Rodrigo Fuentealba <darkprox en gmail.com> wrote:
> El 30/07/07, Ricardo Mun~oz A. <rmunoz en pjud.cl> escribió:
> > Horst H. von Brand wrote:
> > > Ricardo Mun~oz A. <rmunoz en pjud.cl> wrote:

[...]

> > shuata... si es por eso, PostgreSQL tambien corrompe datos[1], da lo
> > mismo en que version tenian X bug donde ocurria... *nadie* me puede
> > asegurar que no ocurra denuevo (no el mismo bug, pero otro con las
> > mismas consecuencias). hay que ser tonto como para no hacer respaldos y
> > confiar ciegamente en un software, da lo mismo cual.

> A ver... depende de lo que definamos por "corromper datos". De acuerdo
> a lo que yo sé, la corrupción de datos implica pérdida o ilegibilidad
> de éstos;

Ojo, no es un item individual del que estamos hablando. P.ej. guardar
solo el nombre y no el RUT de una persona es corrupcion en mis
libros. Tambien el grabar el resultado de restar $$$ de una cuenta sin
sumarselo a la otra. O el eliminar un registro dejando su clave
apuntando a los anillos de Saturno. Para evitar estos ultimos tipos de
problemas es que se definen las propiedades ACID (~~--> wikipedia) como
requisitos indispensables para una base de datos (y en general para
cualquier sistema que procese datos que se respete, ya que estamos en
eso). Y MySQL _no cumple con ellas_. Por *disen~o*, "para hacerlo mas
rapido".

>           MySQL guarda bien "los datos", pero los malabares que hay
> que hacer para que éstos salgan bien formateados

Si no tiene herramientas decentes para formatear datos es un serio punto
con contra, claro. Pero no tiene nada que ver con que sea o no una base
de datos.

>                                                  muchas veces implica
> que hay que hacer las relaciones a nivel de aplicación.

Esto no lo entendi (o mas bien, me parece entender tres cosas diferentes).

>                                                         Algo nada
> apreciable cuando se trata de una base de datos que comparten varias
> aplicaciones, y allá afuera hay miles. Eso no se llama corrupción de
> datos, sino falta de consistencia de los mismos.

Datos no consistentes == datos corruptos.

> PostgreSQL sí asegura la consistencia de los datos mediante varios
> mecanismos (entre ellos, uno que para los que comienzan puede parecer
> sorpresivamente molesto y que es el vacuum, pero que según una
> explicación que leí en el blog de Germán, es bastante beneficioso a la
> larga), y además éstos no se corrompen con tanta facilidad (lo cual en
> ningún caso quiere decir que sea imposible que se corrompan; sólo
> quiere decir que es más difícil).

Insisto: En epocas preteritas vi aplicaciones complejas construidas en
COBOL a punta de archivos VSAM (== indexados mas bien sofisticados de
IBM), que accesaban en forma concurrente varias de ellas al mismo
conjunto de archivos, y eran /muchos/ usuarios. Periodicamente (cada
algunas semanas) se chasconeaban los archivos y habia que reconstruir
alguna cosa medianamente consistente con las piezas...  y las medidas
heroicas para detectar patinazos, recuperar lo rescatable y construir
una vista consistente de los datos restantes era hermoso de contemplar.

Idem MySQL: Si no hay acceso concurrente, OK (la inmensa mayor parte de
las veces tienes un unico usuario de la pagina web; al menos hoy dia,
cuando en unos an~os tu pagina de StoreOfTheCorner se haga el negocio
mas importante del rubro te quiero ver); si a nadie se le ocurre leer
los datos mientras otro los actualiza OK (ver arriba); si a nadie se le
ocurre cortar la energia mientras se modifican, OK (suele ser de interes
del sysadmin que no hayan cortes de energia, por una larga lista de
/otras/ razones). O sea, si, la inmensa mayoria de las veces es
totalmente innecesario. Salvo las pocas veces en que es indispensable, y
/en esos casos/ es que se necesita sin excusas. MySQL es apostar a que
nunca se requerira, y /esa/ clase de apuestas tarde o temprano las pierdes.

[...]

> MySQL por defecto no es un RDBMS. No implementa relaciones si no es
> con InnoDB, que como ya habíamos dicho, no es parte de MySQL
> propiamente tal, sino de Oracle.

Exacto. Por lo mismo usarlo como si fuera un RDBMS es un /crimen/.

[...]

> > > Si, hay areas en las cuales tiene sentido (aplicaciones de
> > > solo consultas simples). Para otros casos, olvidalo.

> Generalmente se evalúa a MySQL para aplicaciones que tienen pocas
> escrituras pero hartas lecturas.

Cierto. Pero la experiencia demuestra que la aplicacioncilla de 3 tablas
con actualizaciones una vez al mes y 15 consultas al dia crece hasta
tener 30 tablas con modificaciones constantes y multiples usuarios
consultando simultaneamente en mucho menos de lo que crees...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513