Algo de bases de datos en Linux...

[Horst H. von Brand]

Rodrigo Fuentealba <darkprox en gmail.com> wrote:
> El 26/07/07, Alvaro Herrera <alvherre en alvh.no-ip.org> escribió:
> > Ovidio Martínez Barco escribió:
> >
> > > Se que Postgres es mejor en capacidad y afinamiento pero por motivos
> > > de fuerza me vi obligado a utilizar MYSQL; que otras cosas debo tener
> > > en cuenta usando esta base de datos MYSQL para que mi aplicación se
> > > conserve siempre estable.

> > Lo unico que debes tener en cuenta es que debes valorar poco tus datos.
> > Si los valoras poco, entonces no tendras ningun problema y siempre sera
> > estable.

> Ejem... MySQL tiene "otros" problemas, pero no creo que su estructura
> de datos sea más volátil que una memoria RAM.

Quien dijo eso?

>                                               Eso es FUD, a mi gusto.

De acuerdo.

> Tienes razón en que si valoras poco tus datos, debes usar MySQL en vez
> de un gestor de verdad, pero hablemos con la verdad: MySQL es lento
> para escribir, tiene exceso de problemas con las formas normales,

Su problema de fondo es que no contempla ACID (y si, cualquier cosa que
no tenga eso no es una base de datos ni por alcance de nombres; no, "si
se aplican encantamientos especiales a las tablas donde importa" no
cuenta).

> tiene un tipo booleano que no es tal sino un unsigned integer (menuda
> manera de desperdiciar espacio),

Cuanto cuesta un disco hoy? Si lo piensas, es _lejos_ lo mas razonable
para almacenar esa clase de datos. Recuerdo que en el libro de Bentley
mencionaba de una aplicacion (cuando las maquinas grandes tenian de unos
64KiB) que "para ahorrar espacio" tenia sus datos codificados en
bitfields en C, y no habia manera de hacerla caber... pasando los
bitfield a char o int, cabia sin problemas (porque el codigo para
empaquetar/desempaquetar era mucho mayor que el ahorro). Y hay que
recordar que las maquinas actuales funcionan a punta de cache... el usar
bits para boolean seguramente sera escandalosamente mas lento para
remate.

>                                  los procedimientos almacenados que
> usa son demasiado malos, no es natural para nada que tenga más de dos
> tablas. Si a eso le sumamos que el soporte InnoDB que hizo Oracle (y
> para el cual se acaba el licenciamiento dentro de poco, por lo que sé)
> es en extremo malo, tienes poderosísimas razones y fundadas
> completamente para NO usar MySQL.

Exacto, los lios de licencia (GPL, o licencia comercial) y siendo Oracle
duen~o de parte vital del motor de datos de MySQL son otros puntos de
peso en contra.

@Book{bentley82:_writing_eff_progr,
  author =       {Jon Louis Bentley},
  title =        {Writing Efficient Programs},
  publisher =    {Prentice Hall},
  year =         1982
}
-- 
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