PostGreSQL vs. MySQL

Hoy en día existen muchas empresas y sitios web que necesitan mantener de forma eficiente un gran volumen de datos. Muchos de ellos optan por soluciones comerciales, aunque muchas otras confían en el software libre optando por una solución como PostGreSQL o MySQL.

En este documento se tratará de hacer una comparativa entre los sistemas de gestión de bases de datos libres más importantes y más usados en la red, los cuales proporcionan soluciones a miles de personas, de forma totalmente gratuita, sin pérdida de eficiencia alguna.

1. Introducción

Común es la pregunta entre las personas que se adentran por primera vez en el mundo de las bases de datos libres: ¿MySQL o PostGreSQL? En realidad no es una pregunta asociada específicamente a los “novatos”, ya que incluso los profesionales dedicados a este campo se realizan muchas veces esta misma pregunta. La verdad es que no es una pregunta fácil de responder, y no carente de grandes controversias.

El objetivo de este documento será introducir las características de estos dos magníficos sistemas de gestión de bases de datos, haciendo una pequeña comparativa entre ellas, con el fin de conducir a la elección más adecuada para cada situación.

2. PostGreSQL

2.1. ¿Qué es PostGreSQL?

PostGreSQL es un sistema de gestión de bases de datos objeto-relacional (ORDBMS) basado en el proyecto POSTGRES, de la universidad de Berkeley. El director de este proyecto es el profesor Michael Stonebraker, y fue patrocinado por Defense Advanced Research Projects Agency (DARPA), el Army Research Office (ARO), el National Science Foundation (NSF), y ESL, Inc.

PostGreSQL es una derivación libre (OpenSource) de este proyecto, y utiliza el lenguaje SQL92/SQL99, así como otras características que comentaremos más adelante.

Fue el pionero en muchos de los conceptos existentes en el sistema objeto-relacional actual, incluido, más tarde en otros sistemas de gestión comerciales. PostGreSQL es un sistema objeto-relacional, ya que incluye características de la orientación a objetos, como puede ser la herencia, tipos de datos, funciones, restricciones, disparadores, reglas e integridad transaccional. A pesar de esto, PostGreSQL no es un sistema de gestión de bases de datos puramente orientado a objetos.

2.2. Historia de PostGreSQL

PostGreSQL (llamado también Postgres95) fue derivado del proyecto Postgres, como ya se ha comentado. A sus espaldas, este proyecto lleva más de una década de desarrollo, siendo hoy en día, el sistema libre más avanzado con diferencia, soportando la gran mayoría de las transacciones SQL, control concurrente, teniendo a su disposición varios “language bindings” como por ejemplo C, C++, Java, Python, PHP y muchos más.

La implementación de Postgres DBMS comenzó en 1986, y no hubo una versión operativa hasta 1987. La versión 1.0 fue liberada en Junio de 1989 a unos pocos usuarios, tras la cual se liberó la versión 2.0 en Junio de 1990 debido a unas críticas sobre el sistema de reglas, que obligó a su reimplementación. La versión 3.0 apareció en el año 1991, e incluyó una serie de mejoras como una mayor eficiencia en el ejecutor de peticiones. El resto de versiones liberadas a partir de entonces, se centraron en la portabilidad del sistema. El proyecto se dio por finalizado en con la versión 4.2, debido al gran auge que estaba teniendo, lo cual causó la imposibilidad de mantenimiento por parte de los desarrolladores.

En 1994, Andrew Yu y Jolly Chen añadieron un intérprete de SQL a este gestor. Postgres95, como así se llamó fue liberado a Internet como un proyecto libre (OpenSource). Estaba escrito totalmente en C, y la primera versión fue un 25% más pequeña que Postgres, y entre un 30 y un 50% más rápida. A parte de la corrección de algunos bugs, se mejoró el motor interno, se añadió un nuevo programa monitor, y se compiló usando la utilidad GNU Make y el compilador gcc sin necesidad de parchearlo (como había hecho falta en versiones anteriores).

En 1996, los desarrolladores decidieron cambiar el nombre a al DBMS, y lo llamaron PostGreSQL (versión 6.0) para reflejar la relación entre Postgres y las versiones recientes de SQL. Se crearon nuevas mejoras y modificaciones, que repercutieron en un 20-40% más de eficiencia, así como la incorporación del estándar SQL92.

La versión que se ofrece a fechas de este escrito, es la versión 7.2.1. Se puede encontrar más información acerca de las características e historia en [PostGreSQL_Manual].

2.3. Características de PostGreSQL

A continuación se enumeran las principales características de este gestor de bases de datos:

  1. Implementación del estándar SQL92/SQL99.
  2. Soporta distintos tipos de datos: además del soporte para los tipos base, también soporta datos de tipo fecha, monetarios, elementos gráficos, datos sobre redes (MAC, IP …), cadenas de bits, etc. También permite la creación de tipos propios.
  3. Incorpora una estructura de datos array.
  4. Incorpora funciones de diversa índole: manejo de fechas, geométricas, orientadas a operaciones con redes, etc.
  5. Permite la declaración de funciones propias, así como la definición de disparadores.
  6. Soporta el uso de índices, reglas y vistas.
  7. Incluye herencia entre tablas (aunque no entre objetos, ya que no existen), por lo que a este gestor de bases de datos se le incluye entre los gestores objeto-relacionales.
  8. Permite la gestión de diferentes usuarios, como también los permisos asignados a cada uno de ellos.

2.4. ¿Qué es lo que le falta?

PostGreSQL es un magnífico gestor de bases de datos, capaz de competir con muchos gestores comerciales, aunque carezca de alguna característica casi imprescindible. Ésta es, bajo mi punto de vista, un conjunto de herramientas que permitan una fácil gestión de los usuarios y de las bases de datos que contenga el sistema. Por otro lado, la velocidad de respuesta que ofrece este gestor con bases de datos relativamente pequeñas puede parecer un poco deficiente, aunque esta misma velocidad la mantiene al gestionar bases de datos realmente grandes, cosa que resulta loable.

2.5. Opinión Personal

PostGreSQL es un magnífico gestor de bases de datos. Tiene prácticamente todo lo que tienen los gestores comerciales, haciéndo de él una muy buena alternativa GPL. A pesar de ello, el primer encuentro con este gestor es un poco “duro”, ya que la sintaxis de algunos de sus comandos no es nada intuitiva. También resulta engorroso las pequeñas variaciones que presenta este gestor en algunos de los tipos de datos que maneja, siendo el problema más comentado el referente al tipo “serial”.

Una vez nos hayamos hecho con su sintaxis y fijándonos en estos pequeños detalles (que por otro lado están totalmente documentados), PostGreSQL es un gestor magnífico, que posee una gran escalabilidad, haciéndolo idóneo para su uso en sitios web que posean alrededor de 500.000 peticiones por día.

3. MySQL

3.1. ¿Qué es MySQL?

MySQL es un sistema de gestión de bases de datos relacional, licenciado bajo la GPL de la GNU. Su diseño multihilo le permite soportar una gran carga de forma muy eficiente. MySQL fue creada por la empresa sueca MySQL AB, que mantiene el copyright del código fuente del servidor SQL, así como también de la marca.

Aunque MySQL es software libre, MySQL AB distribuye una versión comercial de MySQL, que no se diferencia de la versión libre más que en el soporte técnico que se ofrece, y la posibilidad de integrar este gestor en un software propietario, ya que de no ser así, se vulneraría la licencia GPL.

Este gestor de bases de datos es, probablemente, el gestor más usado en el mundo del software libre, debido a su gran rapidez y facilidad de uso. Esta gran aceptación es debida, en parte, a que existen infinidad de librerías y otras herramientas que permiten su uso a través de gran cantidad de lenguajes de programación, además de su fácil instalación y configuración.

3.2. Historia de MySQL

MySQL surgió como un intento de conectar el gestor mSQL a las tablas propias de MySQL AB, usando sus propias rutinas a bajo nivel. Tras unas primeras pruebas, vieron que mSQL no era lo bastante flexible para lo que necesitaban, por lo que tuvieron que desarrollar nuevas funciones. Esto resultó en una interfaz SQL a su base de datos, con una interfaz totalmente compatible a mSQL.

Se comenta en el manual [MySQL_Manual] que no se sabe con certeza de donde proviene su nombre. Por un lado dicen que sus librerías han llevado el prefijo ‘my’ durante los diez últimos años. Por otro lado, la hija de uno de los desarrolladores se llama My. No saben cuál de estas dos causas (aunque bien podrían tratarse de la misma), han dado lugar al nombre de este conocido gestor de bases de datos.

La versión estable de este gestor a días de hoy es la 3.23.49. Se puede encontrar más información sobre este gestor en el manual [MySQL_Manual].

3.3. Características de MySQL

Las principales características de este gestor de bases de datos son las siguientes:

  1. Aprovecha la potencia de sistemas multiprocesador, gracias a su implementación multihilo.
  2. Soporta gran cantidad de tipos de datos para las columnas.
  3. Dispone de API’s en gran cantidad de lenguajes (C, C++, Java, PHP, etc).
  4. Gran portabilidad entre sistemas.
  5. Soporta hasta 32 índices por tabla.
  6. Gestión de usuarios y passwords, manteniendo un muy buen nivel de seguridad en los datos.

3.4. ¿Qué es lo que le falta?

MySQL surgió cómo una necesidad de un grupo de personas sobre un gestor de bases de datos rápido, por lo que sus desarrolladores fueron implementando únicamente lo que precisaban, intentando hacerlo funcionar de forma óptima. Es por ello que, aunque MySQL se incluye en el grupo de sistemas de bases de datos relacionales, carece de algunas de sus principales características:

  1. Subconsultas: tal vez ésta sea una de las características que más se echan en falta, aunque gran parte de las veces que se necesitan, es posible reescribirlas de manera que no sean necesarias.
  2. SELECT INTO TABLE: Esta característica propia de Oracle, todavía no está implementada.
  3. Triggers y Procedures: Se tiene pensado incluir el uso de procedures almacenados en la base de datos, pero no el de triggers, ya que los triggers reducen de forma significativa el rendimiento de la base de datos, incluso en aquellas consultas que no los activan.
  4. Transacciones: a partir de las últimas versiones ya hay soporte para transacciones, aunque no por defecto (se ha de activar un modo especial).
  5. Integridad referencial: aunque sí que admite la declaración de claves ajenas en la creación tablas, internamente no las trata de forma diferente al resto de campos.

Los desarrolladores comentan en la documentación que todas estas carencias no les resultaban un problema, ya que era lo que ellos necesitaban. De hecho, MySQL fue diseñada con estas características, debido a que lo que buscaban era un gestor de bases de datos con una gran rapidez de respuesta. Pero ha sido con la distribución de MySQL por Internet, cuando más y más gente les están pidiendo estas funcionalidades, por lo que serán incluidas en futuras versiones del gestor.

3.5. Opinión Personal

Tras haber probado la PostGreSQL, y viendo las carencias que poseía MySQL, pensé que no merecería la pena ni tan siquiera probarlo, aunque por otro lado, creía que algo debía tener para que hubiera tanta gente que lo use, cuando está a merced de cada uno elegir la base de datos que quiere usar. La verdad es tras haber hecho unas pocas pruebas, mi impresión sobre este gestor mejoró considerablemente.

Para comenzar, el shell de comandos muestra una interfaz más amena y los comandos para gestionar la base de datos son más intuitivos, siendo muchos de ellos sentencias SQL (hay que decir que no dispone de ayuda en línea sobre las palabras clave de SQL). Por otro lado, la API de PHP para acceder a MySQL era muchísimo más sencilla de usar, teniendo un estilo mucho más natural.

Impresiones en contra, la imposibilidad de usar subconsultas, así como también la definición de vistas, aunque según la documentación oficial, éstas dos características serán incluidas en la versión 4.1 aproximadamente (en las versiones actuales, se incluyen dos comandos, LEFT JOIN y RIGTH JOIN, que son capaces de suplir las subconsultas en gran parte de los casos, obteniendo, por otra parte, una mayor eficiencia).

La verdad es que aunque estas diferencias son agradables, no llegan a tener una importancia suficiente como para cambiar el gestor que habitualmente solemos usar. Este tipo de cambios deberían estar basados en diferencias en el rendimiento que se nos ofrece, que es lo que se tratará en el siguiente apartado.

4. Comparativa

4.1. Introducción

Son muchos los benchmarks que se han publicado sobre estos gestores de bases de datos, aunque muchos de ellos tienen una clara tendencia hacia uno de los dos bandos. Es por esto que hay que saber extraer bien las conclusiones a partir de un benchmark. Por ejemplo, es importante que las comparaciones entre los dos gestores se realicen en igualdad de condiciones, cosa que por otra parte, muchas veces resulta complicado debido a las distintas implementaciones que poseen estos gestores.

Además, resulta muy complicado diseñar un buen benchmark, que tenga en cuenta todas las posibles mejoras de rendimiento que pueda aplicar cada uno de estos gestores. Es lógico pues, que haya algunas pruebas que se le apliquen a un gestor, y que no tenga ningún sentido realizarselas al otro.

A continuación se resumen las conclusiones obtenidas a partir de diversos benchmark’s, intentando hacer un descarte de los que tenían una clara tendencia hacia uno de los bandos.

4.2. Lo mejor de PostGreSQL …

Las características positivas que posee este gestor según las opiniones más comunes en Internet, son:

  1. Posee una gran escalabilidad. Es capaz de ajustarse al número de CPUs y a la cantidad de memoria que posee el sistema de forma óptima, haciéndole capaz de soportar una mayor cantidad de peticiones simultáneas de manera correcta (en algunos benchmarks se dice que ha llegado a soportar el triple de carga de lo que soporta MySQL).
  2. Implementa el uso de rollback’s, subconsultas y transacciones, haciendo su funcionamiento mucho más eficaz, y ofreciendo soluciones en campos en las que MySQL no podría.
  3. Tiene la capacidad de comprobar la integridad referencial, así como también la de almacenar procedimientos en la propia base de datos, equiparándolo con los gestores de bases de datos de alto nivel, como puede ser Oracle.

4.3. … y lo peor

Por contra, los mayores inconvenientes que se pueden encontrar a este gestor son:

  1. Consume gran cantidad de recursos.
  2. Tiene un límite de 8K por fila, aunque se puede aumentar a 32K, con una disminución considerable del rendimiento.
  3. Es de 2 a 3 veces más lento que MySQL.

4.4. Lo mejor de MySQL …

Es evidente que la gran mayoría de gente usa este gestor en Internet, por lo que encontrar opiniones favorables no ha resultado en absoluto complicado:

  1. Sin lugar a duda, lo mejor de MySQL es su velocidad a la hora de realizar las operaciones, lo que le hace uno de los gestores que ofrecen mayor rendimiento.
  2. Su bajo consumo lo hacen apto para ser ejecutado en una máquina con escasos recursos sin ningún problema.
  3. Las utilidades de administración de este gestor son envidiables para muchos de los gestores comerciales existentes, debido a su gran facilidad de configuración e instalación.
  4. Tiene una probabilidad muy reducida de corromper los datos, incluso en los casos en los que los errores no se produzcan en el propio gestor, sino en el sistema en el que está.
  5. El conjunto de aplicaciones Apache-PHP-MySQL es uno de los más utilizados en Internet en servicios de foro (Barrapunto.com) y de buscadores de aplicaciones (Freshmeat.net).

4.5. … y lo peor

Debido a esta mayor aceptación en Internet, gran parte de los inconvenientes se exponen a continuación, han sido extraídos de comparativas con otras bases de datos:

  1. Carece de soporte para transacciones, rollback’s y subconsultas.
  2. El hecho de que no maneje la integridad referencial, hace de este gestor una solución pobre para muchos campos de aplicación, sobre todo para aquellos programadores que provienen de otros gestores que sí que poseen esta característica.
  3. No es viable para su uso con grandes bases de datos, a las que se acceda continuamente, ya que no implementa una buena escalabilidad.

5. Conclusión

Después de haber leído diversos artículos sobre estos gestores de bases de datos, FAQ’s y benchmarks (algunos con un curioso “modus operandi”), la conclusión que se puede sacar es que en realidad no hay que sacar ninguna conclusión sobre el tema. Cada uno de estos gestores es idóneo para ciertos campos, e intentar utilizar el otro acarrearía una pérdida de productividad del programa, como también grandes quebraderos de cabeza.

Ninguno de estos dos gestores son totalmente perfectos, por lo que no hay que obcecarse en la elección única y fanática, como se suele hacer en muchos casos de alguno de ellos. Simplemente se trata de escoger el más conveniente en cada caso. Éstos son los grandes inconvenientes y a la vez las grandes maravillas que conlleva el mundo OpenSource.

Como reflexión final, creo que la pregunta con la que se introducía el escritp podría transformarse en: ¿velocidad o potencia?, siendo su carácter mucho más acertado.

Bibliografía

[MySQL_Manual] Manual de MySQL, http://www.mysql.com/documentation/index.html .

[PostGreSQL_Manual] Manual de PostGreSQL, http://www.mysql.com/documentation/index.html .

[Article_MySQL-PostGreSQL] Artículo comparativo, http://www.phpbuilder.com/columns/tim20000705.php3?page=1 .

  • lu32

    Excelente tu comparacion, yo por el momento solo uso MySQL por que estoy dando mis primeros pasos pero me gustaria mucho aprender PostGreSQL.

  • http://danielpecos.com/ Daniel Pecos Martínez

    Muchas gracias! Este documento es algo antiguo ya, y es muy probable que cosas que afirmo en él ya no sean así. Lo que está claro es que ambos sistemas son muy interesantes y el echo de que haya competencia entre ellos no hace otra cosa que mejorar ambos productos.

    • Ernesto Osuna Garzon

      cuanto tiempo tiene este documento?, y si mysql ya soporta gran cantidad de estas cosas que el afirma que no, supongo postgre ha evolucionado igual (por su lado)

      • http://danielpecos.com/ Daniel Pecos Martínez

        Este documento es aproximadamente de 2002 (http://danielpecos.com/documents/).

        Visto el interés sobre este documento, trataré de sacar una revisión actualizada. No he seguido los avances de MySQL y PostgreSQL al detalle, pero es de suponer que gran parte de lo que aquí se dice ya no aplica.

        Ambos motores son muy buenos y han ido mejorando con el tiempo. MySQL forma parte de Oracle y ha tenido un fork reciente llamada MariaDB, por lo que la revisión que haga hablará de estos 3 motores en vez de MySQL vs PostgreSQL.

        • sidihabibi

          Muy buen análisis el del artículo aunque como dices, algunas cosas están ya anticuadas. Desde la versión 5.5 de MySQL el motor por defecto es InnoDB, que sí soporta integridad referencial.
          En cuando a MariaDB, está claro que es una alternativa con más futuro que MySQL y las grandes aplicaciones web (wikipedia, google, etc.) ya se han decantado por MariaDB en sustitución de MySQL

          • http://danielpecos.com/ Daniel Pecos Martínez

            Muchas gracias!

            La verdad es que lo que ha hecho Oracle con MySQL ha sido una lástima. Personalmente creo que fue un intento de anular gran parte de la competencia que tiene Oracle hoy en día, aunque a día de hoy parece que no le ha salido muy bien la jugada.

            Lo de establecer un control sobre un proyecto OpenSource queda demostrado que ni se consigue, ni se elimina al proyecto. Y Oracle concretamente no es la primera vez que lo hace (acordémonos de OpenOffice, derivado en LibreOffice).

          • sidihabibi

            Se me olvidó decir que otra de las cosas por las que me decantaría por PostgreSQL desde el punto de vista de administrador es su cliente de consola psql. El cliente de consola mysql es bueno, pero psql es increíblemente bueno.

  • Jorge

    Como dijo Daniel Pecos, el documento es antigüo pero hay cosas que veo necesario aclarar, porque este artículo aparece en los top de google y mucha gente lo toma de referencia. En particular noto una inclinación a mySQL por razonamientos cuestionables como destacar que mySQL tiene mejor tratamiento de la concurrencia, para unos párrafos abajo indicar que su performance se degrada y luego elogiar el uso de recursos de PostgreSQL indicando su capacidad para la concurrencia. Entonces o bien ambos manejan bien la concurrencia o se debe marcar en qué condiciones uno es superior al otro.

    Primero que nada, respecto a los gestores de usuarios y del server en sí mismo (punto de vista del administrador) hay excelentes herramientas para ambos motores y gratuitas. Incluso las mismas herramientas muchas veces funcionan con ambos motores, con lo cual la dificultad es similar, la curva de aprendizaje también.

    Si se observa el SQL, ya lo has dicho, ni aún hoy en día mySQL tiene soporte completo para alguna versión del estándar SQL (tiene características de sql92/99/2003 pero ninguno completo). Mientras que PostgreSQL lo posee desde su origen y creo que es el único motor que soporta los estándares completos. Esto ayuda mucho cuando se programa o se hacen consultas ad-hoc o cuando se migra de una base de datos existente.

    Algo que me parece muy importante, es que PostgreSQL es totalmente transaccional, es decir que cualquier cosa que se realiza sobre la base tiene un “rollback” (aún cuando no declares un BEGIN TRANSACTION explícitamente en el código). mySQL sólo en sus versiones más nuevas tiene soporte transaccional y no está claro si tiene 100% de cobertura cuando se usan BLOBs y comandos nativos en las sentencias SQL.

    Hablando de eso, ambos motores exponen una serie de poderosos comandos nativos y en este
    aspecto destaco que mySQL permite usar funciones y comandos
    totalmente nativos mezcladas en las sentencias SQL (cosa que PostgreSQL no), lo que a veces ayuda (permitiendo hacer preprocesamiento de datos en las consultas o cosas raras sobre los set de datos) y a veces no (cuando tienes que estimar impactos). Para realizar algo similar en PostgreSQL se emplea el mecanismo de funciones definidas por el usuario, que aunque un poco más trabajoso (hay que declarar la función antes de usarla) es bastante más prolijo e incluso posee excelentes herramientas de
    binding con código nativo que es muy fácil de implementar si es que existe la necesidad de integrarlo con sistemas externos.

    Puestos en el lugar del desarrollador de software, es bastante cierto que existe un ahorro de disgustos si se dispone de el set completo de SQL, para no tener que imaginar workarounds a consultas que debieran ser sencillas, aunque para tranquilidad de los lectores esto ha disminuído bastante (pero no acabado) con las nuevas versiones de mySQL.

    Algo interesante es que PostgreSQL permite definir tipos de datos de usuario complejos, indicando formatos, validaciones, estructura y tiene mejores características para plasmar reglas de negocios, validaciones, etc… Algunas de estas funciones fueron incorporadas en las nuevas versiones de mySQL 4.1+ y 5+, pero son cosas muy útiles y debieran participar de la evaluación.

    Es importante citar el tema de aditamentos, PostgreSQL se puede extender por ejemeplo con PosGIS, que es un módulo que agrega soporte de información geográfica y habilita nuevos tipos de datos e instrucciones para que puedas almacenar coordenadas, mapas, capas, figuras e incluso hacer consultas mixtas utilizando datos de las tablas comunes y los datos nuevos mediante SQL. Otro ejemplo es PostPic, un plugin que agrega el tipo “imagen” para que no uses un blob para guardar un gráfico y además te permite hacer operaciones como devolver secciones de la imagen, consultar sus atributos (ancho, alto, etc…), generar thumbnails, rotar, recortar, etc… directamente en la base de datos.

    Creo que hoy día, la única
    ventaja de mySQL estriba en que las bases de datos pequeñas (de hasta 100 o 200MB) corren más
    rápido y que al tener pocas opciones configurables su uso es más
    sencillo. Pero cuando se debe elegir una base de datos robusta, duradera y de potencia equiparable a motores comerciales como Oracle u SQLServer, me parece que es válido recomendar PostgreSQL.

    Perdón si esto no es lo que quería reflejar el artículo, pero básicamente se habla de velocidad y en mySQL ese factor es bastante dependiente del volúmen de datos y de su estructura, mientras que en PostgreSQL se puede obtener una media pareja.

    • http://danielpecos.com/ Daniel Pecos Martínez

      Hola Jorge,

      No puedo decir otra cosa que muchas gracias por tu aclaración y detalle de todos los puntos que expones. Creo que esta información va a ser muy útil para la gente que lea este artículo.

      Yo creo que es difícil decantarse por MySQL o PostGreSQL sin tener en cuenta el contexto donde se vayan a utilizar. Por ejemplo, creo que MySQL es una de las BDs más utilizadas en paginas web, y que en muchos casos es complicado reemplazarla por un gestor distinto, ya que los productos más utilizados suelen recomendar ésta (WordPress, phpbb, oscommerce…), aunque sí que es verdad que muchos dan soporte para distintos gestores de bases de datos.

      Por otra parte, en entornos corporativos con una gran base de usuarios tal vez me decantaría por un PostGreSQL, ya que parece un entorno más acorde para este gestor, aunque de nuevo, habría que ver qué uso se le va a dar, en qué entorno se va a implantar (y qué aplicaciones van a interactuar con la BD) y qué tipo de datos se van a almacenar.

      En resumen, cada gestor tendrá puntos fuertes y puntos débiles en situaciones distintas, y lo ideal es conocerlos todos lo mejor posible, para así poder tomar la mejor decisión.

      De nuevo, muchas gracias por tu aporte!

Code, opinions and some other geek-stuff

Follow

Get every new post delivered to your Inbox

Join other followers: