Algo de bases de datos en Linux...

[Rodrigo Fuentealba]

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:
> >
> > [...]
> >
> >> el punto es que no puedes descartar de antemano el uso de una
> >> herramienta solo porque a ti no te ha funcionado (siempre tomar en
> >> cuenta PEBKAC) o sabes de algunos casos similares.
> >
> > Cierto.
> >
> >
> >>                                                    si las distros
> >> Linux ofrecen MySQL es obvio que MySQL sirve,
> >>
> >
> > Es obvio que hay quienes usan MySQL, nada mas. La ley de Sturgeon dice
> > que 95% de cualquier cosa es basura...
> >
>
> ok. segun el Doc, el 95% del software que trae una distro Linux es
> basura... gran revelacion!
>

Gnome :-X tuvo varios dramas con CORBA. Hay distros que suelen
empaquetar todo lo que pillen.

> >>                                               y que no corrompe datos,
> >
> > Lo hace.
>
> 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; MySQL guarda bien "los datos", pero los malabares que hay
que hacer para que éstos salgan bien formateados muchas veces implica
que hay que hacer las relaciones a nivel de aplicación. 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.

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

> >> y que todo el FUD al respecto que aparece en esta lista tiene la
> >> explicacion logica de que Alvaro es desarrollador de Postgres.
> >
> > No. Alvaro /sabe/ de RDBMSes. Y hay otros que saben al respecto tambien
> > aca.

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.

> >        Y entre los que saben el consenso es que MySQL _no sirve_ para
> > bases de datos en serio,

Porque como mínimo para una base de datos en serio tiene que asegurar
no sólo la data, sino también las relaciones. Gracia que hasta
Microsoft Access tiene.

> > porque no tiene las caracteristicas minimas
> > exigibles.

ACID, SQL92/SQL99 Compliant, Procedimientos Almacenados Complejos,
etc. Sí, me van a decir que en la página de MySQL dice que sí, y que
el estándar es confuso y complejo y que cada provider lo implementa a
su pinta, pero si todos los demás pudieron, ¿por qué MySQL no?

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

> > Que es "funcionando muy bien"? Que *garantias* ofrece de mantener
> > integridad de los datos?
> >
>
> Doc, no leyo bien... se trataba de un CD de solo consulta. los datos
> eran una imagen de una base en Oracle, que se supone es robusta y donde
> no se pierden datos... ;)
>

No tan verdadero. Oracle tuvo en su oportunidad errores sin parchar
desde hace más de 900 días. Eso es casi 3 años.

http://www.informationweek.com/showArticle.jhtml;jsessionid=KS4MZLWXGNJ2EQSNDLPSKH0CJUNN2JVN?articleID=201002057

> [1] http://archives.postgresql.org/pgsql-sql/2001-04/msg00392.php

Abril del 2001; eso fue hace ya bastante tiempo, y por lo que sé, en
ese tiempo PostgreSQL tenía su pasado oscuro. Bueno, yo comencé a usar
PostgreSQL 7.1 y sí, en ese tiempo igual se me caía a veces con
errores bastante feos (algo así como en septiembre del 2001), pero
también he visto cómo ha mejorado.

Bueno, igual creo que mi socio tiene las respuestas que necesitaba
para decidir qué database engine va a usar, así es que opino que
continuemos la música...

-- 
Rodrigo Fuentealba Cartes
Desarrollador de Sistemas - Consultor UNIX - Database Administrator