MySQL y PostgreSQL son, sin duda, las dos bases de datos libres más empleadas. Con los años, a base de leer artículos, blogs, comentarios, etc. me fui haciendo una idea vaga de los puntos fuertes y los puntos débiles de cada una de ellas; cosas como, por ejemplo, que MySQL era más rápida pero PostgreSQL tenía una mayor protección de la integridad de los datos. Pero, a la hora de la verdad, tampoco hubiera puesto la mano en el fuego asegurando que esas "impresiones" que yo me fui haciendo de las dos bases de datos eran realmente correctas, ni podría haber referenciado una fuente fiable para defender las virtudes de una u otra (estoy seguro que a más de uno de vosotros
En FLOSS Weekly, un podcast dedicado al software libre que pertenece a la red TWIT, han realizado recientemente una entrevista a Josh Berkus, empleado de Sun (aunque esto no es relevante) cuya labor dentro de la empresa está completamente orientada a la base de datos PostgreSQL (Sun ofrece soporte para ella). Durante la entrevista hizo una comparación entre MySQL y PostgreSQL .
Aunque a priori pudiera parecer que tiene motivos para no ser neutral, sus opiniones me parecen sinceras y no tuvo reparos en indicar cuáles serán los puntos en los cuales MySQL era superior (probablemente más que en los que es inferior). Por otro lado, todo lo que dijo iba en la línea de las "impresiones" que yo tenía; os dejo aquí los puntos que desde mi punto de vista son más interesantes:
La entrevista es un recurso muy interesante para hacerse una idea de las ventajas y desventajas de cada uno de las bases de datos.
¿Estáis de acuerdo con los comentarios de Josh Berkus?
Otra bd que esta también "emergiendo" es SQLite que es más ligera que MySQL ya que no abre ningún puerto.
Es decir, ¿puede decirse que Mysql está limitado en proyectos importantes? Por importante me refiero a aplicaciones bancarias, por ejemplo. ¿Alguien tiene experiencias que digan lo contrario?
Sobre el primer punto, me gustaría aclarar que MySQL tiene mejor rendimiento en consultas de selección (y siempre que no sean anidadas). En consultas complejas la diferencia es inexistente o mínima. Tengamos en cuenta que la diferencia tan grande en rendimiento existía con MySQL 4, ahora que MySQL ya tiene triggers, soporta selects anidados, etc. la diferencia es mínima (antes era comparar churras con merinas). Por otra parte, la documentación de PostgreSQL me parece excelente. Personalmente, ya no considero MySQL como opción por el siguiente motivo. Para aplicaciones medias y grandes, prefiero la potencia de PostgreSQL. Para proyectos pequeños tanto PostgreSQL como MySQL se me pueden quedar grandes, y me parece preferible usar una BBDD más sencilla como SQLite o, si la aplicación es en Java, incluso una incrustada del tipo HSQL o Derby.
En el proyecto en el que trabajo usamos PostgreSQL, y realmente es robusta, porque de momento no hemos tenido ningun problema de corrupcion de datos. Algo que se valora mucho aqui, porque antes con DBF (era una aplicacion foxpro) era infernal la de veces que se iba al garete la DB.
Sobre la velocidad, de momento no me quejo. Quiza fuese mas rapida MySql, no lo se. Pero salvo algun informe con consultas algo complejas, que le cuesta (como a todas, digo yo) , responde bastante bien.
Nosotros usamos MySQL para montar entornos de pruebas y desarrollo, en producción de momento jamas hemos podido montar una base de datos como MySQL o PostgreeSQL porque nuestros clientes (bancos fundamentalmente) no aceptan otra cosa que no sea SQL-Server o Oracle.
Por lo general los clientes "grandes" suelen tener licencias y contratos con microsoft, oracle, ibm (db2), DBA's formados en estas bases de datos... al menos en mi experiencia en aplicaciones para compañias "gordas" no hay posibilidad de usas estas bd's libres, y no por razones tecnicas, más de una aplicación que hemos montado tiraría perfectamente en un MySQL.
No nos olvidemos de Firebird
Seguramente en mi caso el tema venga que en su momento consideramos que el postgres 7.x era superior al mysql 3.x, ya que este último no tenía vistas. A día de hoy no sabría decir cual es mejor, pero si puedo garantizar que postgreSQL funciona muy bien con proyectos pequeños y medianos. Como nota decir que la nueva Web de javaHispano funciona con Postgres 8.2.
Una característica a considerar a la hora de elegir es la licencia. Mysql es GPL (y los drivers también) mientras no adquieras licencia de uso y Postgresql es bsd. Eso quiere decir que si realizas un proyecto y lo distribuyes, con la primera puedes tener algún problema y con la segunda no.
esa razon, la de la licencia, es por la que nuestra aplicación migró de MySql a PostgreSQL. Pero yo no tuve nada que ver que no estaba en la empresa :)
"Berkus afirma que en aquellos escenarios en los cuales no podemos permitirnos que se corrompa o se pierda ni un solo registro (por ejemplo, aplicaciones médicas o bancarias) sólo es una opción PostgreSQL."
Suficiente argumento (si es verdad) para tirar MySQL a la basura.
Anónimo, creo que eres un poco radical. Hay muchas aplicaciones en las que no es esencial que se pierda ningun registro. Por ejemplo, los comentarios de las noticias de javaHispano ;). MySQL ha demostrado ser suficientemente buena para millones de aplicaciones reales (incluido javaHispano hasta la semana pasada). Pero hay aplicaciones (transferencias bancarias, por ejemplo) donde uno no se puede permitir que desaparezca ni un solo registro aunque alguien tiere del cable de corriente del servidor. Y es ahí donde habría que considerar otras opciones.
Wow por primera vez leo comentarios que no son todos pro-MySQL, que ha ganado tanto un publicidad por eso de que todos los proyectos PHP incorporan una BD MySQL y pocas PostgreSQL. Recuerdo hace unos dos años haber leído un blog sobre un sitio muy famoso, tipo slashdot, en el cual querían hacer esa comparación en vivo entre las dos BD. Al final lo único que tenían que hacer era cambiar el string de conexión de una base a otra. Con MySQL el tiempo de respuesta era mucho más rápido que postgreSQL sobretodo cuando no había mucha gente conectada, luego de un tiempo cuando la carga era demasiada, los tiempo se iban degradando poco a poco, y al final la base se caía sistemáticamente bajo carga. Con postgreSQL, al principio el sitio respondía menos velozmente que con mySQL, pero poco a poco la carga iba subiendo la base de datos seguía proporcionando las informaciones con la misma prontitud, ni se mosqueaba, y al final bajo muchísima carga la base seguia funcionando, no se cayo ni una vez y apenas daba signos de estar soportando tanta carga. Ahora no sé como hallan evolucionado las dos BD últimamente, pero en aquel entonces si que postgreSQL era la solución ideal para cualquier proyecto serio. (eso sin tomar en cuenta que en esa epoca MySQL no tomaba todavía ni siquiera los SELECT imbricados). Aunque he de decir que hace poco me toco hacer un proyecto PHP-MySQL y que MySQL había mejorado muchisimo en cuanto a los stored procedures, el lenguaje SQL soportado etc... me impresionó como había evolucionado.
A mi parecer, mysql esta creciendo muchisimimo mas rapido que postgre, es cosa de recordar las funciones q ambos tenian 1 año atras y las diferencias en capacidades que tienen ahora. Referente a la integridad de datos....tal como decian arriba, ninguna empresa con datos importantes usaria estas opciones para manejar sus bases de datos.
Bueno una vez en mi empresa tratamos de utilizar postgres pero encontramos problemas cuando una se realizaban inserciones masivas en una tabla o varias tablas, pasada las 1000 inserciones se perdía el rendimiento totalmente y tocaba hacer vacum pero como nuestra aplicación iba a recibir bastante carga decidimos optar por otra base de datos. Para nuestro caso una de pago.
Cuando se habla de MySQL nos podemos referir a varias tecnologías distintas, por ejemplo las bases de dato de tipo INNODB o MYISAM. Me imagino que todas estas comparaciones están realizadas con las bases de dato de tipo INNODB. Incluso al parecer, desde que Oracle compró la empresa propietaria de la tecnología que está detrás de las bases de datos INNODB, MySQL inicio el proceso de construcción de una nueva tecnología contratando para ello a uno de los creadores de Firebird.
Hola Lo que no se menciona mucho es que PostgreSql se puede trabajar como Base de Datos Orientado a Objetos, según leí, las consultas son muchísimas mas rápidas que cuando las tablas son relacionales, solo he realizado pequeñas pruebas y me ha parecido fenomenal , Tal ves pueda ser mucho mas rápido que Mysql (solo es un suposición), si lo trabajamos de manera Orientada Objetos. ¿Que opinan Uds? Saludos!
"Mysql es GPL y Postgresql es bsd. Si realizas un proyecto y lo distribuyes, con la primera puedes tener algún problema y con la segunda no."
Que MySQL tenga licencia GPL no obliga a que tu aplicación, que se conecta a MySQL, sea también GPL. Por el mismo razonamiento cualquier aplicación que corre en un Linux tendría que ser GPL...
Puedes distribuir tu producto y MySQL en el mismo CD-ROM sin ningún problema.
Tu producto sólo deberá ser GPL si es un producto derivado de MySQL, por ejemplo, un gestor de bases de datos SuperMySQL+
Tu producto sólo deberá ser GPL si es un producto derivado de MySQL, por ejemplo, un gestor de bases de datos SuperMySQL+
Correcto, no es lo mismo utilizar una base de datos que modificar el código fuente y hacerla pasar por tuya.
Pero os hago una pregunta curiosa.
Si hago un programa comercial que necesita MySQL y lo incluyo en mi CD de instalación, ¿estoy saltandome la licencia GPL? ¿Que pensais?
Ooops quice decir tablas INNODB y MyISAM (y no base de dato).
El asunto de la licencia de MySQL es un poco enredado, por decirlo de alguna manera.
Si nos basamos solo en lo que dice la GPL es como dicen que solo si el producto es derivado del código fuente de MySQL que también obligaría a liberar las fuentes con la misma licencia. Sin embargo, si se lee con cuidado la página de MySQL da a entender algo distinto (o al menos a mi me parece).
http://www.mysql.com/company/legal/licensing/faq.html
http://www.mysql.com/company/legal/licensing/index.html
Hola, soy el anónimo que decía que una aplicación que usa MySQL no tiene por qué ser GPL (tengo un usuario en javahispano pero sólo lo uso cuando tengo algo inteligente que decir)
En efecto, en los links que pone ricardo se da a entender que no puedes usar MySQL si tu aplicación es GPL, pero yo creo que es una manera de meter miedo para que se pague la licencia comercial.
Digan lo que digan los de MySQL en su web, la licencia GPL es la licencia GPL, y si tu sólo usas una aplicación GPL, sin tocar el código ni hacer ningún producto derivado, la GPL no te infecta.
Insisto en mi ejemplo de Linux, yo corro mis aplicaciones en Linux y eso no las obliga a ser GPL, o mis aplicaciones llaman a una funcion de C de Linux sin tener que ser GPL.
El tema del driver Connector-J me despista un poco. Aunque no forma exactamente parte de mi aplicación, sino que lo pongo en el servidor de aplicaciones.
El problema que tiene es que la empresa te dice que MySql tiene la licencia GPL siempre y cuando tu proyecto sea opensource, caso contrario la licencia que aplica es la de pago.
Lo de las licencias es un buen lio.
Si MySQL se distribuye bajo GPL tu puedes usarla mientras cumplas con los terminos de la licencia GPL sea tu proyecto comercial o no, esto de "si tu proyecto es comercial entonces te afecta la licencia de pago" es algo que no tiene ningún sentido, lo pondrán como decian antes un poco por meter miedo y que la gente pague una licencia para evitarse lios.
Lo que no tengo tan claro es el tema de si usas MySQL y los drivers son GPL, al tener que linkar (esto en C/C++... en java poner un .jar en el runtime classpath que para el caso es lo mismo) con tu desarrollo, en teoría tu desarrollo se ve afectado por "el virus" GPL y debe ser también GPL. Según esto que al menos yo siempre lo he entendido así (si no para que se habrían inventado lo de classpath excepción para liberar el jdk??) si en tu aplicación usas los drivers de MySQL tu aplicación debe ser también GPL, o bien optar por solicitar una licencia de pago y usar MySQL bajo los terminos de esta otra licencia.
Claro que como en realidad lo que te afecta es la licencia de los drivers y no los de la propia bd, siempre podrías usar el puente jdbc-odbc y de esta forma no tendrías en tu classpath nada GPL y entonces ningún problema ¿no?, juas que lio :P
Yo tenia entendido que si tu aplicacion tiene animo de lucro, has de pagar licencia a MySql, y si no, no.
"Yo tenia entendido que si tu aplicacion tiene animo de lucro"
Cuando un software se distribuye bajo una licencia siempre que yo cumpla los terminos de esa licencia lo puedo usar. Si MySQL se distribuye bajo GPL mientras yo cumpla con la GPL la puedo usar independientemente de si tengo o no tengo animo de lucro o cualquier otra circunstancia. El tema de las licencias duales es, si yo no puedo o no quiero cumplir con las restricciones de, en este caso, la GPL, pues entonces puedo obtener de MySQL una licencia de uso de su software en otras condiciones que si me interesen. De lo que me tengo que preocupar es de que dice la licencia GPL y de si me supone alguna restricción que no pueda cumplir, no de si mi proyecto es comercial o con animo de lucro, no son cosas excluyentes, puedo perfectamente tener animo de lucro y cumplir la GPL, en ese caso no tengo porque solicitar a MySQL ninguna licencia de pago ya que cumplo con las condiciones de la licencia bajo la que distribuyen su software y todo es perfectamente legal.
Por ejemplo yo puedo hacer GPL también el código de mi proyecto y seguir perfectamente teniendo animo de lucro. En realidad en muchos proyectos comerciales o a medida esto no creo que supusiera mucho problema. Le cobro al cliente por hacerle el desarrollo a medida y una vez que se lo hecho lo libero bajo GPL, en realidad el código de una aplicación "a medida" tipica de gestión no tiene mucho (o ningún) valor. Unos cuantos formularios con Acceso a BD por aqui y por alla lo sabe hacer cualquiera, el valor esta en que yo le hago al cliente justo los que a el le hacen falta, pero probablemente el código no sea muy reutilizable ni aprovechable para ninguna otra cosa, así que ¿que más me da liberarlo o no liberarlo bajo GPL?. Otra cosa diferente es si libero alguna pieza de código (algoritmos o cosas así) que de un factor diferencial a mi compañia, entonces probablemente no me compense liberar bajo GPL, pero ¿en cuantos proyectos de los tipicos de gestión se incluyen algoritmos o diseños que realmente den este valor diferencial?. Creo que la gente le tiene excesivo aprecio al código, en realidad el código en si no vale mucho, el patrimonio de una compañia de desarrollo de soft no esta en apilar montones y montones de lineas de código guardaditas en un servidor, esta en disponer de la capacidad y los conocimientos para escribir esas lineas de código. Yo creo que esto es algo que mucha gente todavía no entiende y siguen viendo en esto de liberar el código algo así como "regalar" el trabajo de su compañia, probablemente porque no han terminado de entender de que va la pelicula esta de hacer software.
Efectivamente. es como dices. De hecho antes el driver jdbc era LGPL con lo que podías hacer con tu aplicación lo que quisieras ya que no linkabas a código GPL. Luego los de MySQL contrataron al tipo que mantenía el driver y modificaron la licencia. En todo caso, queda claro que si tu distribuyes tu software con las librerías de Mysql tienes que optar por una licencia compatible GPL y distribuir el código si distribuyes la aplicación. Como la mayor parte de las empresas suelen tener reticencias a soltar su código con licencia GPL hay que tener cuidadin con esta parte, o asumir que en el caso de distribuir tu programa, tienes que comprar licencias de mysql.
mira, ya se una cosa mas. Es que yo con las licencias me hago la picha un lio. Pero tenía esa impresion de MySql, precisamente porque en mi proyecto fin de carrera usé MySql, y mi tutora me indicó que pusiera en el proyecto cuanto valía la licencia, porque para uso comercial había que pagar. Cosas de la universidad y sus profesores.
Volviendo al tema, un anonimo comentaba que si en "postgres insertabas muchas filas de golpe perdía rendimiento". Uno de los problemas más comunes con postgres < 8.0 es que antes era necesario realizar "vacums" periódicos de las tablas. Esto actualmente es automático, pero antes era necesario realizarlo periódicamente.
Con respecto a lo de las licencias, la licencia la pone el dueño de los fuentes y sólo el dueño puede determinar bajo que licencia te da a ti su producto. La empresa dueña de MySQL dice que si tu proyecto cumple ciertas licencias opensource entonces tu proyecto puede usar tranquilamente MySql caso contrario te toca usar la licencia de pago. Esa es la licencia de uso que te da la empresa, es GPL sólo para ciertos casos. La única excepción que ponen es con PHP si tu programa está hecho en php entonces tu puedes darle la licencia que quieras a tu proyecto y no tienes que hacerlo GPL. Con respecto a lo que dice lasterra ¨Uno de los problemas más comunes con postgres < 8.0 es que antes era necesario realizar "vacums" periódicos de las tablas. Esto actualmente es automático, pero antes era necesario realizarlo periódicamente. ¨ considero que el problema se mantiene, aún teniendo el autovacum activo depués de varias inserciones repetitivas sobre una tabla el rendimiento se pierde de manera exponencial y toca ejecutar el vacum y eso también te quita rendimiento. La versión de postgres con la que probé era 8.0 sobre windows XP de pronto pueda ser por eso. Con todo voy a hecharle un nuevo vistaso a la versión 8.3 a ver que cambia.
Como muy bien dice lasterra y volviendo al rendimiento, la verdad es que la mayoría de las comparativas "actuales" que he podido encontrar se refieren a un mysql bastante antiguo, la nueva versión 5.1 ya trae casi de todo a saber: triggers, stored, si quieres integridad referencial la obtienes según el formato de la tabla que elijas, yo personalmente estoy ahora evalúando cúal escoger para un proyecto de datawarehouse (si alguien conoce alguna comparativa entre las dos para un data ó lo ha probado en sus carnes agradecería la aportación) y la verdad es que mysql con los tipos de tablas que puede manejar INNODB, MYISAM, etc té dá una flexibilidad según la aplicación (incluso dentro de la misma aplicación para realizar varias cosas) que desconozco si postgres tiene, es más nosé como estará en postgres el tema de replicación y cluster, si viene integrado ó hay que recurrir a terceros y aflojar la mosca. Si alguien tiene información sobre ello ó algún link de comparativas actuales al respecto agradeceríamos el aporte para aclarar un poco el bosque. Saludos.
El tema es muy interesante y el resultado final de la ecuacion todos quisieramos tener de eso no hay duda. A mi experiencia he usado tanto mysql y postgres(SIG) pero por lo menos en mi pais no me imagino una banco o empresa fuerte usando tales db. Siempre se usa db2, Ms sql server, Oracle. para lo que se usan estas bd mysql y postgres son para pymes(empresas de medianao en proceso) donde el uso libre de estas ayuda a diluir costos de produccion
"Bueno una vez en mi empresa tratamos de utilizar postgres pero encontramos problemas cuando una se realizaban inserciones masivas en una tabla o varias tablas, pasada las 1000 inserciones...." Te comento que en mi empresa no hemos tenido los problemas que tuviste, todo lo contrario, PostgreSQL fué nuestra salvación luego de probar MySql, que está claro va de pelos cuando los datos que se manejan son relativamente pocos. En todo caso, la experiencia que tenemos con PostgreSQL hace referencia a una aplicación que maneja aproximadamente 60 millones de registros por mes, y ojo, es información que recibimos en archivos que luego tenemos que pasarlos a la BD en un solo proceso. La integridad de datos, lo potente, robusto y completo que es PostgreSQL, cuando se lo sabe usar, nos hicieron decidirnos por el.
Nuevamente hablando del rendimiento, lo que me queda claro (por los comentarios y mi experiencia) es que el rendimiento depende de muchos factores, como por ejemplo la configuraciòn ("cuando se sabe usar" ... o no) y las condiciones (procesador, memoria, sistema operativo), etc. Vamos, seguro que estoy diciendo algo obvio, pero por ahì se nos puede pasar. Por ejemplo, hace no mucho (unos dos meses) cargamos unos scripts de MySQL en un Windows XP y tardaron como 3 horas en ejecutarse. Luego, instalamos en el mismo equipo Ubuntu Linux y con el respectivo MySQL ... los scripts tardaron menos de 10 minutos en ejecutarse ... ¿de que dependió exactamente esa diferencia? ... no tuvimos tiempo de averiguarlo. Por lo que recuerdo Postgres ha sido desarrollado para trabajar en ambientes *unix y posiblemente el rendimiento en Windows no sea de lo mejor (es solo una suposición).
En el tema de la licencia, antes MySQL tenía una propia que venia a decir que la podias utilizar si tu proyecto era libre y que tenias que pagar si no.
Ahora MySQL es GPL puro y duro, es decir que a menos que modifiques su código fuente no te "infecta".
En cuanto al driver... tengo entendido (aunque en Mysql.com intentan asustarte) que si tu aplicación esta basada en puro JBDC y no tienes las referencias al driver en el código fuente (e.j. cargas el nombre del driver y la URL de la BBDD de un fichero de configuracion), tu no estas "linkando" con el driver MySql sino con la interfaz JBDC por lo que tampoco te afecta, es decir una línea de texto en un fichero externo no se puede considerar un "linkado"
Saludos
JuanDavi
Ohhh, son duras la comparaciones aquí les escribo un caso real, con esto no quiero decir que MySQl sea mas robusto o mas rápido sino que respondía para lo que requería.
CASO 1: En MySQL4 en UNIX todos los días realizo proceso de comparaciones (INNER JOIN) de 2 tablas entre 80 a 100 mil registros, como no tiene store procedure yo cree un script en php background y lo ejecuto todo los días con un crontab.
Este script realiza comparaciones de uno a muchos (es decir de 1 registro de la tabla de 80 mil a todos los registros de la tabla de 100 mil) el proceso lo ase en 20 a 30 segundos, y mueve todo el resumen a otra tabla para hacerlo mas fácil luego la consulta. Hasta aquí no he tenido problemas todo trabaja bien EN BACK GROUP, pero si ases este tipo de comparaciones directamente en el phpmyadmin o en Query Browser es realmente muy pesado y posiblemente nunca veas el resultado. (También no creo que alguien se de un tiempo largo de ver un reporte de mas 100 mil registros en el phpmyadmin o Query Browser)
CASO 2: Migre mi base de datos de sql server 2000 a mysql 5 con MySQL Migration Tollkit, la base de datos en sql server pesa 580 MB y cuando la migre termino pesando 320 MB, es decir optimizo la base de datos hasta aquí todo bien todos los registros completos y sin errores.
Cuando realice consultas con cruce de información de 10 líneas aproximadas de INNER JOINS se demoraba mucho, pero encontré el problema, era los índices y las llaves primarias que no estaban definidas luego de la migración. Luego de fijar el problema ahora las consultas las ase rápido y mas aun cuando pase la consulta a un strore procedure.
Lo bueno que el MySQL tiene el LIMIT que permite paginar las consultas en el SQL y de esta manera no cargas demasiado.
Ahora también todo depende que tan bien este administrada tu base de datos, esto puede ayudar en mucho al rendimiento del MYSQL
Joel JDV.
"Que MySQL tenga licencia GPL no obliga a que tu aplicación, que se conecta a MySQL, sea también GPL. Por el mismo razonamiento cualquier aplicación que corre en un Linux tendría que ser GPL..."
Primeramente, cuando se habla de GPL se está hablando de una familia de licencias y versiones incompatibles o semiincompatibles. GPLv1, GPLv2, LGPL ... y actualmente está a punto de salir la GPLv3.
Segundo, creo que la mayor parte de vosotros jamás leyo la licencia GPL y si la leyo probablemente no tuvo en cuenta que está redactada usando tecnicismos legales, no está en el usual inglés técnico y la que vale es la versión pura en inglés...
Tercero, ya se comento de pasada que MySQL hace una excepción en la licencia con PHP, eso se debe a que tal como se licenciaba MySQL te obligaba a que tu aplicación en PHP fuese también GPL debido a que PHP está bajo licencia BSD imcompatible con GPL, incluso siendo teóricamente ilegal usar PHP con MySQL, de ahí que comenzo a inclusión de SQLite a partir de PHP 5. Lo que significaria que de la noche a la mañana la mayor parte de las instalaciones de MySQL migraran a otras Bases de Datos... y los de MySQL no son tontos y por eso hacen la excepción con PHP.
Cuarto, con lo anterior y comentando cosas ya dichas: si tu usas MySQL en servidor y te conectas con ODBC u otro metodo similar que legalmente hace que tu aplicación no estea conectada fisicamente con MySQL (podrías sustituir MySQL por Oracle y a lo sumo cambiar media docena de lineas de código) pues no hay problemas legales. Pero si MySQL es un componente principal o accesorio de tu aplicación entonces o pagas licencia comercial o teóricamente tu aplicación tiene que ser GPL, aunque no haya ni una línea de código usada o no uses los drivers... y por qué? pues porque tal como está redactada la GPL (y será mucho peor con la GPLv3), si tu usas código (fuente u objeto, vease binarios) GPL en una aplicación, esa aplicación tiene que ser GPL o licencia compatible como LGPL. Tanto da que uses un truco como usar un archivo de texto, ese archivo es fundamental en la aplicación y en si es el vinculo... En este caso usar MySQL es el equivalente a usar una libreria liberada en GPL...
Quinto: por lo escrito en el parrafo anterior es por lo que muchas distribuciones de linux directamente o ya no inclullen código propietario (aunque sean aplicaciones freeware) o lo hacen en CDs separados... y es que puede habler problemas de licencias. Por ello excepto en Linspire/FreeSpire y un par de distribuciones más no se incluyen codecs, drivers (los de las targeta de video suelen ser freeware en cambio no se incluyen por eso)...
Sexto: La licencia GPL está diseñada para forzar a usarla, incluso si tu ves código fuente de una aplicación protegida con GPL y después tu escribes una aplicación similar, aunque no uses ni una linea de código, pues estás obligado a que tu aplicación sea GPL. Incluso muy teóricamente tendrías que a partir de la visión del código protegido por GPL licencias todo el código que hagas como GPL...
Septimo: La licencia GPL es tremendamente restrictiva, es una de las licencias más restrictivas que existen y está diseñada para serlo. Y no solo eso, lo simpatico es que cuando haya aplicaciones protegidas por la GPLv3, pues alguna de esas aplicaciones es incompatible por ejemplo con Windows, legalmente tu no podrías usar una aplicación protegida pro la GPLv3 en software parcialmente protegido con patentes de software... en cristiano, tu solo puedes usar aplicaciones GPLv3 con otras aplicaciones GPLv3, LGPL, GPLv2 y muy pocas más, entre ellas las de Mozilla.
Un Saludo
"Segundo, creo que la mayor parte de vosotros jamás leyo la licencia GPL"
Sí, es que a nosotros nos gusta hablar por hablar sin tener ni puta idea, no como tú que habla de una manera fundamentada.
"La licencia GPL es tremendamente restrictiva, es una de las licencias más restrictivas que existen y está diseñada para serlo"
Restrictiva en el sentido de proteger al desarrollador, que es donde la GPL infecta, cuando haces un producto a partir de otro GPL.
Pero en el caso de una base de datos, lo que hacemos es conectarnos a ella mediante un socket, quizá yo no entienda los tecnicismos legales, pero cualquier desarrollador entiende que una aplicación y el gestor de bases de datos al que se conecta son aplicaciones diferentes.
A ver. La licencia de Mysql no te afecta para usarla desde java, pero la del driver JDBC si, porque lo lincas a tu código. Y la licencia del driver también es GPL. Si encuentras un driver JDBC con otra licencia no deberías tener mas problema, como era antes, que el driver era LGPL.
Luego está lo que se dice que la GPL defiende al programador. Estupendo, pero las decisiones de licencias no las toman normalmente los programadores sino las empresas. Y eso de ir dando sus fuentes a todo quisque no les suele gustar nada.
GPL "infecta" al "derived work" no es un microbio que infecta a todo lo que este a su alrededor.
Dudas espefícas en http://www.gnu.org/licenses/gpl-faq.html
Volviendo al tema. Desde mayo estoy leyendo articulos y demas para empararme en el tema. No he encontrado una documentacion de "puesta en marcha" de PostgreSQL. Menos en Windows. Y en castellano ni hablar.
Aprovecho para solicitarles direccion de donde poder descargar tutoriales que expliquen en forma sencilla como armar unas tablas y relaciones.
Postgres en espanol: www.postgresql.cl
Trabajaba antes con mysql y ahora lo hago con PostgreSQL, en todo sentido siento que la informacion que manejo esta bien respaldada. respecto al articulo donde dice que postgresql es para sistemas en donde no se puede corromper ni un solo registro..... pienso que nadie quiere que le pase eso. prefiero un par de milisegundos mas a tener la duda si la informacion esta segura o no. Por otro lado antes tenia una aplicacion en mysql con la misma estructura que ahora tengo en postgresql y tenia que hacer consultas con subconsultas sobre tablas con mas de 200.000 registros y con mysql demoraba mas de 2 minutos en responder y con postgresql teniendo la misma estructura y consulta solamente 4.5 segundos. de verdad no se de donde sacan que postgresql es mas lento.
Yo use las dos en Windows para ver ccn cual Sustituir Sql Server, consultando con un Select a una tabla MySql superaba a Access y casi empataba con SQLSERVER, Postgresql estaba ahi tambien, pero cuando tenia que hacer joins de dos o mas tablas ahi gana PostgreSQL y como trabajo con sistemas que tienen Views y Funciones complejas, PostgreSQL fue la solucion.
Para los que dicen que no pueden hacer algo robusto si no es con bd propietarias les digo que Postgresql soporta la BD de una red de pagos muy importante en el mercosur.
Y que solo Oracle puede superar en algunos puntos su rendimiento lo que hace postgresql la mejor bd si de evaluar la relacion costo benefico se trata
Buenas, realmente nunca probe postgre (lo estoy instalando en este momento mientras escribo). Por cuestiones de migracion nunca intente nisiquiera probarlo... Mi duda siempre fue (la estoy por probar ahora mismo) si la forma de crear bases, tablas, procedures, etc (los tipos de campos etc) son iguales entre postgresql y mysql... Si es asi seria lindo dar la opcion al cliente entre las dos bases de datos.
Hola a todos, alguien se le ha perdido aunque sea un byte de sus tablas en mysql ?... He usado MySQL desde la version 4 ahora con la 5 veo que este software ha adquirido más poder. Yo le apuesto a MySQL, pronto les tocará los talones a Posgres si es ya no se los ha tocado.
---ghOzt ---
q onda estuve leyendo un poco del articulo q escribieron y coincido en unas cosas y me atrevi a decir lo q pienso por q he usado tanto mysql como postgress y realmente existe una gran diferencia entre el volumen de informacion q manejas ademas del tiempo de respuesta q arrojan ahora se los dejo a su decision depende para q lo vayan a utilizar escojan su manejador de bds tomen en cuenta q tambien existe firebird. Pero los mas usados es mysql y postgresss
hola todos tengo un problema que resolver y es el siguiente:
En una empresa que abandono Windows 2000 y XP por pasarse a Linux se encontró que ellos trabajan con una aplicación cliente en Windows que esta siendo emulada en cada equipo Linux lo que hace que la aplicación corra un 20% mas lenta que lo normal y se generen errores inesperados, los datos de la aplicación se encuentran almacenados en una base de datos PostgreSQL.
Se que PostgreSQL es mejor y es soft libre, pero que recomendacion podemos darle a esta empresa? gracias agradesco su colaboracion
Anonimo
Yo quisiera saber si alguien me puede ayudar diciendome si es muy complicado migrar una base de datos de postgress a mysql server 5.0, y me de una idea. Por que postgress no se manejar
Un benchmark que usé (20'000.000 de registros) en 4 equipos exactamente iguales usando 4 bases de datos diferentes arrojó los siguientes resultados
MySQL 5.1 Lectura = 11 Secs MyISAM 21 Secs InoDB Escritura 47 Secs MyISAM 187 Secs InoDB
PostGresQL 8.0xx Lectura 37 Secs Escritura 149 Secs
Oracle 11g Lectura 17 Secs Escritura 99 Secs
MsSQL 2008 Express Lectura 39 Secs Escritura 149 Secs.
Hay que tener en cuenta que son consultas e insersiones sencillas a una sola tabla. La misma tabla con tipos de datos equivalentes. Longitud total de registro de 278 caracteres 7 cosl. Un indice primario y uno secundario. Filtros con y sin índice. Sin embargo, todo depende de la configuración del servidor de base de datos.
Personalmente no he tenido problemaas de corrupción de información con MySQL, con volúmenes de 10 - 15 millones de registros mensuales en windows 2003 server 100 - 150 usuarios simultáneos. Usamos MySQL por su velocidad y facilidad de manejo y configuración. Además MySQL tiene replicación dentro de si misma mientras que PosgresQL necesita de terceras partes. La replicación de MySQL es hasta 10 veces mas rápida que las que conozco en Postgres.
Opino que ambas son excelentes opciones y aunque respeto todos los puntos de vista, estoy en desacuerdo con aquellos que opinan que estas dos DB no son aptas para trabajo 'pesado' empresarial. He tenido trabajo muy intenso (Varios clubes con múltiples restaurantes) y ninguna de las dos se ha colgado nunca.
GerVal
holas a todos y felicidades por los comentarios exelentes,
yo tengo solo experiencia en mySQL y ahora mismo estoy probando el 5.1, pero lo que asusta un poco que me an dicho que ay problema en integridad.
Tampoco veo las compraciones en en ambiente de trabajo pesado fiscicamente como ser los equipos en lugares no adecuado que en el mundo real sucede y escapa muchas veces al control nuestro ya sea porque el cliente pinsa que eso no es importante y que el sistema debe responder en todos los casos, como ser por falta de mantenimiento el equipo se rcalienta todo y se esta colgando mucho, pero que reiniciando funciona otra ves y asi hasta que se solucione y pasa 1,2, o varios dias. Tambien que las limpiadoras en horas pico desconecta un cable porque es nueva y no sabia que no tenia que entrar ay. Esta cosa se debe considerar a la hora de la prueba cortando o apagando el equipo, yo se que es tedioso pero se debe considerar. Estaba seriamente pensando en pasar en Posgres por la integridad ya que perder unos milisegundo mas y si voy a ganar seguridad que es lo mas importante.
Tambien seria importante que se incluya sobre que version de cada producto se hace cada comentario porque algunas cosas ya se solucionaron y al parecer no se enteran los que emiten su opinion
Hola a todos, estuve leyendo su información y me parece interesante, solo unas preguntas:
¿en donde trabajo se utiliza mucho ACCESS y para mas de 5 millones de registros se utiliza SQL server, se requiere migrar la información a open source (tal como openoffice) pero BASE de openoffice no provee lo esperado, estamos definiendo una base de datos pero no sabemos si MySQL o Postgres, el caso es que la información solo es para ob tener fines estadísticos y no interactua con usuarios externos. lo que si se requiere es que sea multiprocesos...algua recomendación...greacias
Ya decía yo que tardaban en salir los "Tengo un problema de nosequé... ayuda". Me ha parecido fascinante el post, de verdad...
Por cierto, alguien me podría ayudar a... jaja, es coña.
Ya decía yo que tardaban en salir los "Tengo un problema de nosequé... ayuda". Me ha parecido fascinante el post, de verdad...
Por cierto, alguien me podría ayudar a... jaja, es coña.
Después de leer tanto. La elección es fácil, Postgresql. Por que las diferencias técnicas para bien o para mal, son relativamente pequeñas. Pero la diferencia brutal, es que Postgresql es licencia BSD, puedes hacer lo que te de la gana.
Me he sacado todas las dudas,,, Gracias a todos...
Interesante, no me dedico a la informática pero en mi trabajo tuve la necesidad de empezar a conocer las bases de datos. Los datos que manejamos son datos de pacientes con lo cual ese comentario de que MySQL no debería ser una opción en estas circunstancias me llamó la atención en este foro. En windows MySQL parece intentar hacerle fácil las cosas a nosotros los que no somos informáticos, No hay que lidiar con el case-sensitive. Los esquemas en postgresql son muy útiles pero si no los necesitas te complican la vida a la hora de hacer las consultas (tenes que escribir más), el conector ODBC es más complejo en postgresql (¿ANSI o UNICODE?, para importar una tabla en un esquema particular tuve que dar en muchos foros) en definitiva Postgresql te exige un poco más de "tiempo" (Time is money como dicen los gringos). MySQL es más intuitivo, tiene Triggers, Subconsultas, la gestión de usarios parece suficiente. Supongo que para especialistas en el tema lo que estoy diciendo no tiene mucha importancia pero no todos los que manejamos bases de datos somos especialistas en el tema. Respecto a el tema del procesamiento les paso mi pequeño aporte. En el mismo servidor (1Gb RAM, un solo núcleo) - tengo entendido que PG con varios nucleos saca mucha diferencia- Una consulta compleja en una tabla con 300.000 registros y 20 campos, configurados los gestores como vienen por defecto luego de la instalación.
MySQL 7,710 seg
PostgreSQL 10,047 seg.
Ahora bien - y estos es para Berkus - una hermosa comparativa pongo las ventajas y desventajas de los productos pero al final te tiro una frase como -y bueno si no queres perder ningun registro no uses MySQL- es tendencioso. ¿Quien quiere usar gestor que pierde registros así sea una página web de recetas de cocina?. Me parece que ese tipo de comentarios debe seguirse de evidencia. No digo que Berkus no la tenga pero me gustaría conocerla. ¿Alguien tuvo experiencias de perdidas de datos? Saludos. Diego Argentina.
Voy a probar con Postgres, trabaje con Mysql y InnoDb y no tuve problemas de peridida de registros, pero ahora tengo mucha experiencia con Oracle y esta es super Robusta... y por lo que he leido.. Postgres se parece más... permite PgSql, consultas de sql más avanzadas.. mientras que probe los triggers en mysql y no les veo mucho poder....
Considero que todo está en función de las necesidades de los proyectos, es decir, hay proyectos donde no se maneja grandes cantidades de registros, motivo por el cual, sugiero el uso de MySQL, caso contrario Postgresql.
Quien es mejor???? el SMBD que esté acorde al proyecto a realizar. Oracle, SQL Server, son SMBD muy bueno, pero, a lo mejor no a la altura de los bolsillos de los clientes (Licencia), esto sin duda, los deja fuera de la jugada.
Quien es mejor???? considero que el SMBD que este acorde a nuestro análisis de proyecto... o no???
Escribe tu comentario