Rodrigo Fuentealba <[EMAIL PROTECTED]> wrote: > El 30/07/07, Ricardo Mun~oz A. <[EMAIL PROTECTED]> escribió: > > Horst H. von Brand wrote: > > > Ricardo Mun~oz A. <[EMAIL PROTECTED]> 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
