Alvaro Herrera escribió: > Ricardo Mun~oz A. escribió: >> Ernesto Esteban del Campo Cárcamo wrote: >>> Debo dar mi experiencia. >>> >>> Tenia un sistema de Ordenes de trabajo en MySQL con tablas en InnoDB y >>> MyISAM el cual luego un par de años y miles de registros comenzo a >>> volverse lento. >>> >>> Se migró a PostgreSQL y debido a que es RELACIONAL todo funcionó más >>> rápido. >> en que aspecto es PostgreSQL mas "relacional" que MySQL? > > Yo me pregunto lo mismo ...
Que es nativamente relacional. En MySQL es una _opcion_ usar relacionalidad, lo cual es consistente ya que nunca he visto que MySQL se autodenomine un RDBMS. > Sin embargo hay una cosa que es cierta, y es que el optimizador de > consultas de Postgres es mucho mas inteligente que el de MySQL. Entonces se puede deducir que los desarrolladores de PostgreSQL son mas inteligentes que los de MySQL ;-) > Cuando > tienes consultas que hacen mas de unos pocos joins, no es nada de > sorprendente que Postgres las ejecute en menos de un segundo, mientras > que en MySQL tardan muchisimo tiempo. Si bien no lo he comprobado objetivamente, aca tengo tablas con algunos miles de registros en donde una vista los relaciona hasta con expresiones complejas, es decir, mas de una expresión( unidas por AND u OR en el ON del JOIN), y sí, a veces esas vistas devuelven otros miles de registros en menos el 75% de un segundo... > En estos casos, en MySQL se > sugiere usar modelos menos normalizados (lo vi en algun manual), o > extraer datos en dos pasadas y luego hacer un pseudo-join en el codigo > de la aplicacion. Quizas por esto uno pueda decir que es "menos > relacional", porque te obliga a que uses modelos menos limpios. Exacto, o quizas casi nada relacional.. -- Juan Martinez G. Mac Iver # 370 Departamento de Informatica 4997900 - 4997934 Universidad Miguel de Cervantes Santiago - Chile http://download.bblug.usla.org.ar/netiquette.png From [EMAIL PROTECTED] Tue Jul 31 19:43:46 2007 From: [EMAIL PROTECTED] (=?ISO-8859-1?Q?Germ=E1n_Po=F3_Caama=F1o?=) Date: Tue Jul 31 20:09:06 2007 Subject: Algo de bases de datos en Linux... In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> On Tue, 2007-07-31 at 15:35 -0400, Juan Martínez wrote: > Alvaro Herrera escribió: > [...] > > En estos casos, en MySQL se > > sugiere usar modelos menos normalizados (lo vi en algun manual), o > > extraer datos en dos pasadas y luego hacer un pseudo-join en el codigo > > de la aplicacion. Quizas por esto uno pueda decir que es "menos > > relacional", porque te obliga a que uses modelos menos limpios. > > Exacto, o quizas casi nada relacional.. Hay ocasiones, que por rendimiento se deben relajar las restricciones de integridad, relajar la normalización del modelo, no usar transacciones y todo lo que nos enseñaron que hacían los chicos buenos, obedientes y ordenados. Digamos cuando hay miles de millones de tuplas involucradas y con acceso concurrentes. Joe Gregorio indica que allí las bases de datos relacionales pueden quedar chicas. http://bitworking.org/news/158/ETech-07-Summary-Part-2-MegaData Allí se indica una referencia a como lo hacen en eBay: http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf en donde la base de datos solo es un repositorio. El resto de la lógica se maneja arriba (Oracle de por medio). Interesante, aunque parezca básico, los problemas de utilizar 'autoincrement' y como se iba de guata MySQL en del.icio.us (por cierto, harto feo el sitio ese :-). http://joshua.schachter.org/2007/01/autoincrement.html Aunque lo más entretenido se encuentra en: http://www.guardian.co.uk/g2/story/0,,1824525,00.html (citado en el sitio de Joshua Schachter) sobre la debilidad de exponer números en serie. Aunque como no estamos hablando de sitios como eBay o de sucesos como iLike (que pasó a crecer a una tasa de 300.000 usuarios/día), probablemente todo esto es pura ficción y la discusión sobre quien tiene la última palabra debiera seguir. -- Germán Poó Caamaño Concepción - Chile
