This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.- English language: This article is a translation from English into Spanish, published under license «Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0) », written by Ostezer and Mark Drake, published on line by the company for leasing virtual machines DigitalOcean. The tittle is «SQLite vs MySQL vs PostgreSQL: A Comparison Of Relational Database Management Systems» and we created a copy at Wayback Machine for prevent in future a broken link. This work is licensed under the mencioned license but, of course, in castilian language (AKA spanish): «Atribución-NoComercial-CompartirIgual 4.0 Internacional (CC BY-NC-SA 4.0) ».
Esta obra está bajo una Licencia Creative Commons Atribución-NoComercial-CompartirIgual 4.0 Internacional.- En castellano: Este artículo es una traducción del inglés al castellano, publicado bajo licencia (en idioma inglés) «Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0) » escrito por Ostezer y Mark Drake, publicado en línea por la empresa de alojamiento de máquinas virtuales DigitalOcean. El título original en idioma inglés es «SQLite vs MySQL vs PostgreSQL: A Comparison Of Relational Database Management Systems» y hemos creado una copia en Wayback Machine para prevenir un posible enlace roto a futuro.
El modelo de datos relacionales, que organiza los datos en tablas de filas y columnas, predomina en los instrumentos de gestión de bases de datos. Hoy en día existen otros modelos de datos, incluidos el NoSQL y el NewSQL, pero los sistemas de gestión de bases de datos relacionales (SGBDR) siguen siendo dominantes para el almacenamiento y la gestión de datos en todo el mundo.
En este artículo se comparan y contrastan tres de los RDBMS de código abierto más utilizados: SQLite, MySQL y PostgreSQL. Específicamente, explorará los tipos de datos que utiliza cada SGBDR, sus ventajas y desventajas, y las situaciones en las que se optimizan mejor.
Tabla de contenido:
Un poco sobre los sistemas de gestión de bases de datos
Las bases de datos son grupos de información o datos modelados lógicamente. Un sistema de gestión de bases de datos (SGBD), por otro lado, es un programa informático que interactúa con una base de datos. Un SGBD permite controlar el acceso a una base de datos, escribir datos, ejecutar consultas y realizar cualquier otra tarea relacionada con la gestión de la base de datos. Aunque a los sistemas de gestión de bases de datos se les suele denominar «bases de datos», ambos términos no son intercambiables. Una base de datos puede ser cualquier colección de datos, no sólo una almacenada en una computadora, mientras que un SGBD es el software que permite interactuar con una base de datos.
Todos los sistemas de gestión de bases de datos tienen un modelo subyacente que estructura la forma en que se almacenan los datos y se accede a ellos. Un sistema de administración de bases de datos relacionales es un SGBD que emplea el modelo de datos relacionales. En este modelo, los datos se organizan en tablas, que en el contexto de los SGBD se denominan más formalmente relaciones. Una relación es un conjunto de tuplas, o filas en una tabla, y cada tupla comparte un conjunto de atributos, o columnas:
La mayoría de las bases de datos relacionales utilizan un lenguaje de consulta estructurado (SQL) para gestionar y consultar los datos. Sin embargo, muchos SGBDR utilizan su propio dialecto particular de SQL, que puede tener ciertas limitaciones o extensiones. Esas extensiones suelen incluir características adicionales que permiten a los usuarios realizar operaciones más complejas que las que podrían realizar con el SQL estándar.
Nota: El término «SQL estándar» aparece varias veces a lo largo de esta guía. Los estándares SQL son mantenidos conjuntamente por el Instituto Nacional Americano de Estándares (ANSI), la Organización Internacional de Normalización (ISO) y la Comisión Electrotécnica Internacional (IEC). Siempre que en este artículo se menciona el «estándar SQL» o «el estándar SQL», se está refiriendo a la versión actual del estándar SQL publicado por estos organismos.
Cabe señalar que la norma SQL completa es grande y compleja: el cumplimiento del núcleo completo de SQL:2011 requiere 179 características. Por ello, la mayoría de los SGBDR no son compatibles con la norma completa, aunque algunos se acercan más al cumplimiento total que otros.
A cada columna se le asigna un tipo de datos que dicta qué tipo de entradas se permiten en esa columna. Los diferentes RDBMS implementan diferentes tipos de datos, que no siempre son directamente intercambiables. Algunos tipos de datos comunes incluyen fechas, cadenas, números enteros y booleanos.
Los tipos de datos numéricos pueden estar signados, lo que significa que pueden representar tanto números positivos como negativos, o sin signo, lo que significa que sólo pueden representar números positivos. Por ejemplo, el tipo de datos tinyint de MySQL puede contener 8 bits de datos, lo que equivale a 256 valores posibles. El rango con signo de este tipo de datos va de -128 a 127, mientras que el rango sin signo es de 0 a 255.
A veces, el administrador de una base de datos impondrá una restricción en una tabla para limitar los valores que pueden ser introducidos en ella. Una restricción se aplica típicamente a una columna en particular, pero algunas restricciones también pueden aplicarse a toda una tabla. A continuación se presentan algunas restricciones que se utilizan comúnmente en SQL:
UNIQUE: La aplicación de esta restricción a una columna asegura que no haya dos entradas idénticas en esa columna.NOT NULL: Esta restricción asegura que una columna no tenga ningún valor de tipo nulo (NULL).PRIMARY KEY: una combinación deUNIQUEyNOT NULL, la restricciónPRIMARY KEYasegura que ningún valor entrante en la columna sea nuloNULLy, además, que cada valor introducido sea distinto a los ya registrados.FOREIGN KEY: es una columna en una tabla que se refiere a laPRIMARY KEYde otra tabla. Esta restricción es utilizada para enlazar así a dos tablas: las entradas a la columnaFOREIGN KEYdebe existir en la columna padrePRIMARY KEYpara que el proceso de escritura sea exitoso.CHECK: esta restricción limita el rango de valores que pueden ser introducidos en una columna. Por ejemplo, si vuestra aplicación está destinada solo para los residentes del estado de Alaska (EE. UU.), usted podría adicionar un restricciń tipoCHECKen la columna del código postal apra que solo acepte valores entre 99501 y 9950.DEFAULT: esto proporciona un valor por defecto para la columna. A menos que otro valor sea especificado, SQLite introduce el valor por defecto de manera automática.INDEX: utilizado para ayudar a obetenr datos de una tabla de manera rápida, esta «restricción» es parecida al ínidec de un libro: en vez de revisar por entero la tabla, una consulta solo tiene que revisar entradas indexadas de la columna para encontrar los resultados deseados.
Si quiere saber más sobre los sistemas de gestión de bases de datos, consulte nuestro artículo sobre «Comprensión de las bases de datos SQL y NoSQL y los diferentes modelos de bases de datos».
Ahora que hemos cubierto los sistemas de gestión de bases de datos relacionales en general, pasemos a la primera de las tres bases de datos relacionales de código abierto que cubrirá este artículo: SQLite.
SQLite
SQLite es un SGBDR autónomo, basado en archivos y de código abierto, conocido por su portabilidad, fiabilidad y fuerte rendimiento incluso en entornos con poca memoria. Sus transacciones son compatibles con ACID, incluso en casos en los que el sistema se bloquea o sufre un corte de energía.
El sitio web del proyecto SQLite lo describe como una base de datos «sin servidor». La mayoría de los motores de bases de datos relacionales se implementan como un proceso de servidor en el que los programas se comunican con el servidor anfitrión a través de una comunicación interprocesada que retransmite las peticiones. Con SQLite, sin embargo, cualquier proceso que acceda a la base de datos lee y escribe directamente en el disco de la base de datos. Esto simplifica el proceso de configuración de SQLite, ya que elimina cualquier necesidad de configurar un proceso de servidor. Asimismo, no es necesario configurar los programas que utilizarán la base de datos de SQLite: sólo necesitan acceder al disco.
SQLite es un software libre y de código abierto, y no se requiere ninguna licencia especial para utilizarlo. Sin embargo, el proyecto ofrece varias extensiones, cada una de ellas por un precio único, que ayudan a la compresión y el cifrado. Además, el proyecto ofrece varios paquetes de apoyo comercial, cada uno de ellos por una cuota anual.
Tipos de datos admitidos por SQLite
SQLite permite una variedad de tipos de datos, organizados en las siguientes clases de almacenamiento:
| Tipo de dato | Descripción |
|---|---|
null | Incluye cualquier valor de tipo nulo. |
integer | Enteros con signo, almacenados en 1, 2, 3, 4, 6, u 8 bytes dependiendo de la magnitud del valor. |
real | Números reales, o valores de punto flotante, almacenados como números de coma flotante de 8 bytes. |
text | Cadenas de texto almacenadas usando la codificación de la base de datos, que puede ser UTF-8, UTF-16BE o UTF-16LE. |
blob | Cualquier objeto binario grande o BLOB, exactamente como fue introducido. |
En el contexto de SQLite, los términos «clase de almacenamiento» y «tipo de datos» se consideran intercambiables. Si desea obtener más información sobre los tipos de datos y la afinidad de los tipos de SQLite, consulte la documentación oficial de SQLite sobre el tema.
Ventajas de SQLite
- Tamaño reducido: como su nombre lo indica (lite), la biblioteca SQLite es muy ligera. Aunque el espacio que utiliza varía según el sistema donde está instalado, puede ocupar menos de 600 KB de espacio. Además, es totalmente autónomo, lo que significa que no hay dependencias externas que deba instalar en su sistema para que SQLite funcione.
- Facilidad de uso: SQLite se describe a veces como una base de datos de «configuración cero», es decir, que está lista para su uso desde el principio. SQLite no se ejecuta como un proceso de servidor, lo que significa que nunca necesita ser detenido, iniciado o reiniciado y no viene con ningún archivo de configuración que deba ser administrado. Estas características ayudan a agilizar el camino desde la instalación de SQLite hasta su integración con una aplicación.
- Portátil: a diferencia de otros sistemas de administración de bases de datos, que generalmente almacenan datos como un gran lote de archivos separados, una base de datos SQLite completa se almacena en un solo archivo. Este archivo puede ubicarse en cualquier lugar de una jerarquía de directorios y puede compartirse a través de medios extraíbles o protocolo de transferencia de archivos.
Desventajas de SQLite
- Concurrencia limitada: Aunque varios procesos pueden acceder y consultar una base de datos SQLite al mismo tiempo, sólo un proceso puede realizar cambios en la base de datos en un momento dado. Esto significa que SQLite admite una mayor concurrencia que la mayoría de los demás sistemas de gestión de bases de datos incorporados, pero no tanto como los SGBDR cliente/servidor como MySQL o PostgreSQL.
- Sin administración de usuarios: los sistemas de bases de datos a menudo vienen con soporte para usuarios o conexiones administradas con privilegios de acceso predefinidos a la base de datos y las tablas. Debido a que SQLite lee y escribe directamente en un archivo de disco ordinario, los únicos permisos de acceso aplicables son los permisos de acceso típicos del sistema operativo subyacente. Esto hace que SQLite sea una mala elección para aplicaciones que requieren múltiples usuarios con permisos de acceso especiales.
- Seguridad: un motor de base de datos que utiliza un servidor puede, en algunos casos, proporcionar una mejor protección contra errores en la aplicación cliente que una base de datos sin servidor como SQLite. Por ejemplo, los punteros perdidos en un cliente no pueden dañar la memoria en el servidor. Además, dado que un servidor es un proceso único y persistente, una base de datos cliente-servidor puede controlar el acceso a los datos con más precisión que una base de datos sin servidor, lo que permite un bloqueo más preciso y una mejor concurrencia.
Cuando usar SQLite
- Aplicaciones integradas: SQLite es una excelente opción de base de datos para aplicaciones que necesitan portabilidad y no requieren expansión futura. Los ejemplos incluyen aplicaciones locales de un solo usuario y aplicaciones móviles o juegos.
- Reemplazo del acceso al disco: En los casos en que una aplicación necesita leer y escribir archivos en el disco directamente, puede ser beneficioso utilizar SQLite por la funcionalidad adicional y la simplicidad que conlleva el uso de SQL.
- Pruebas: para muchas aplicaciones puede ser excesivo probar su funcionalidad con un DBMS que utiliza un proceso de servidor adicional. SQLite tiene un modo en memoria que se puede usar para ejecutar pruebas rápidamente sin la sobrecarga de las operaciones reales de la base de datos, por lo que es una opción ideal para las pruebas.
Cuando no utilizar SQLite
- Trabajando con muchos datos: SQLite puede soportar técnicamente una base de datos de hasta 140TB de tamaño, siempre y cuando la unidad de disco y el sistema de archivos también soporten los requisitos de tamaño de la base de datos. No obstante, el sitio web de SQLite recomienda que toda base de datos que se aproxime a 1 TB se aloje en una base de datos centralizada cliente-servidor, ya que una base de datos de SQLite de ese tamaño o mayor sería difícil de gestionar.
- Grandes volúmenes de escritura: SQLite permite que se realice una sola operación de escritura en un momento dado, lo que limita considerablemente su rendimiento. Si su aplicación requiere muchas operaciones de escritura o varios escritores simultáneos, SQLite puede no ser adecuado para sus necesidades.
- Se requiere acceso a la red: Dado que SQLite es una base de datos sin servidor, no proporciona acceso directo a la red a sus datos. Este acceso está incorporado en la aplicación, por lo que si los datos de SQLite se encuentran en una máquina separada de la aplicación, se necesitará un enlace de gran ancho de banda entre el motor y el disco en toda la red. Esta es una solución cara e ineficiente, y en tales casos un SGBD cliente-servidor puede ser una mejor opción.
MySQL
Según el sitio web Ranking DB-Engines, MySQL ha sido el SGBDR de código abierto más popular desde que el sitio comenzó a rastrear la popularidad de la base de datos en 2012. Es un producto rico en funciones que impulsa muchos de los sitios web y aplicaciones más grandes del mundo, incluidos Twitter, Facebook , Netflix y Spotify. Comenzar a usar MySQL es relativamente sencillo, gracias en gran parte a su exhaustiva documentación y a su gran comunidad de desarrolladores, así como a la abundancia de recursos en línea relacionados con MySQL.
MySQL fue diseñado para velocidad y confiabilidad, a expensas de la total adherencia al SQL estándar. Los desarrolladores de MySQL trabajan continuamente para lograr una mayor adherencia al SQL estándar, pero aún está rezagado con respecto a otras implementaciones de SQL. Sin embargo, viene con varios modos y extensiones SQL que lo acercan al cumplimiento. A diferencia de las aplicaciones que usan SQLite, las aplicaciones que usan una base de datos MySQL acceden a ella a través de un proceso de demonio separado. Debido a que el proceso del servidor se encuentra entre la base de datos y otras aplicaciones, permite un mayor control sobre quién tiene acceso a la base de datos.
MySQL ha inspirado una gran cantidad de aplicaciones de terceros, herramientas y bibliotecas integradas que amplían su funcionalidad y ayudan a facilitar su trabajo. Algunas de las herramientas de terceros más utilizadas son phpMyAdmin, DBeaver y HeidiSQL.
Tipos de datos admitidos por MySQL
Los tipos de datos de MySQL pueden organizarse en tres grandes categorías: tipos numéricos, tipos de fecha y hora y tipos de cadenas.
Tipos numéricos
| Tipo de dato | Descripción |
|---|---|
tinyint | Un número entero muy pequeño. El rango con signo para este tipo de datos numéricos es de -128 a 127, mientras que el rango sin signo es de 0 a 255 |
samllint | Un entero pequeño. El rango con signo para este tipo numérico es de -32768 a 32767, mientras que el rango sin signo es de 0 a 65535. |
mediumint | Un entero de tamaño medio. El rango con signo para este tipo de datos numéricos es de -8388608 a 8388607, mientras que el rango sin signo es de 0 a 16777215. |
int o integer | Un entero de tamaño normal. El rango con signo para este tipo de datos numéricos es de -2147483648 a 2147483647, mientras que el rango sin signo es de 0 a 4294967295. |
bigint | Un número entero grande. El rango con signo para este tipo de datos numéricos es de -9223372036854775808 a 9223372036854775807, mientras que el rango sin signo es de 0 a 18446744073709551615. |
float | Un pequeño número de coma flotante (precisión simple). |
double, double precision o real | Un número normal de coma flotante (precisión doble). |
dec, decimal, fixed o numeric | Un número de coma fija empaquetado. La longitud de visualización de las entradas para este tipo de datos se define cuando se crea la columna, y cada entrada se adhiere a esa longitud. |
bool o boolean | Un booleano es un tipo de datos que sólo tiene dos valores posibles, normalmente verdadero o falso. |
bit | Un tipo de valor de bit para el que puede especificar el número de bits por valor, de 1 a 64. |
Tipos de fecha y tiempo
| Tipo de dato | Descripción |
|---|---|
date | Una fecha, representada como AAAA-MM-DD. |
datetime | Una marca de tiempo que muestra la fecha y la hora, mostrada como AAAA-MM-DD HH:MM:SS. |
timestamp | Una marca de tiempo que indica la cantidad de tiempo transcurrido en Tiempo Unix (00:00:00 del 1 de enero de 1970). |
time | Una hora del día, mostrada como HH: MM: SS. |
year | Un año, ya sea expresado en formato de 2 ó 4 dígitos, por defecto en la forma más larga.default. |
Tipos de cadena de texto
| Tipo de dato (nombre reservado) | Descripción |
|---|---|
char | Una cadena de longitud fija; las entradas de este tipo se rellenan a la derecha con espacios para cumplir con la longitud especificada cuando se almacenan. |
varchar | Una cadena de longitud variable |
binary | Similar al tipo char, pero con una cadena de bytes binarios de una longitud determinada en lugar de una cadena de caracteres no binarios. |
varbinary | Similar al tipo varchar, pero con una cadena de bytes binarios de longitud variable en lugar de una cadena de caracteres no binarios. |
blob | Una cadena binaria con una longitud máxima de 65535 (2 ^ 16 - 1) bytes de datos. |
tinyblob | Una columna de blob con una longitud máxima de 255 (2 ^ 8 - 1) bytes de datos. |
mediumblob | Una columna de blob con una longitud máxima de 16777215 (2^24 - 1) bytes de datos. |
longblob | Una columna de blob con una longitud máxima de 4294967295 (2^32 - 1) bytes de datos. |
text | Una cadena con una longitud máxima de 65535 (2 ^ 16 - 1) caracteres. |
tinytext | Una columna de text con una longitud máxima de 255 (2 ^ 8 - 1) caracteres. |
mediumtext | Una columna de text con una longitud máxima de 16777215 (2^24 - 1) caracteres. |
longtext | Una columna de text con una longitud máxima de 4294967295 (2^32 - 1) caracteres. |
enum | Una enumeración, que es un objeto de cadena que toma un solo valor de una lista de valores que se declaran cuando se crea la tabla. |
set | Similar a una enumeración, un objeto de cadena que puede tener cero o más valores, cada uno de los cuales debe elegirse de una lista de valores permitidos que se especifican cuando se crea la tabla. |
Ventajas de MySQL
- Popularidad y facilidad de uso: Como uno de los sistemas de base de datos más populares del mundo, no faltan administradores de bases de datos con experiencia en MySQL. Asimismo, hay abundante documentación en papel y en línea sobre cómo instalar y administrar una base de datos MySQL, así como una serie de herramientas de terceros -como phpMyAdmin- que tienen por objeto simplificar el proceso de inicio de la base de datos.
- Seguridad: MySQL viene instalado con un guión que ayuda a mejorar la seguridad de su base de datos estableciendo el nivel de seguridad de la contraseña de la instalación, definiendo una contraseña para el usuario root, eliminando las cuentas anónimas y eliminando las bases de datos de prueba que son, por defecto, accesibles a todos los usuarios. Además, a diferencia de SQLite, MySQL admite la gestión de usuarios y permite conceder privilegios de acceso usuario por usuario.
- Velocidad: Al elegir no implementar ciertas características de SQL, los desarrolladores de MySQL pudieron priorizar la velocidad. Si bien las pruebas de referencia más recientes muestran que otros SGBDR como PostgreSQL pueden igualar o al menos acercarse a MySQL en términos de velocidad, MySQL sigue teniendo la reputación de ser una solución de base de datos excesivamente rápida.
- Replicación: MySQL admite varios tipos diferentes de replicación, que es la práctica de compartir información entre dos o más anfitriones para ayudar a mejorar la fiabilidad, la disponibilidad y la tolerancia a las fallas. Esto es útil para establecer una solución de respaldo de la base de datos o para escalar horizontalmente la propia base de datos.
Desventajas de MySQL
- Limitaciones conocidas: Debido a que MySQL fue diseñado para la velocidad y la facilidad de uso en lugar del cumplimiento total de SQL, viene con ciertas limitaciones funcionales. Por ejemplo, carece de soporte para las cláusulas
FULL JOIN. - Licencias y características propietarias: MySQL es un software con doble licencia, con una edición comunitaria gratuita y de código abierto bajo licencia GPLv2 y varias ediciones comerciales pagas lanzadas bajo licencias propietarias. Debido a esto, algunas características y complementos solo están disponibles para las ediciones propietarias.
- Desarrollo lento: Desde que el proyecto MySQL fue adquirido por Sun Microsystems en 2008, y posteriormente por Oracle Corporation en 2009, ha habido quejas de los usuarios de que el proceso de desarrollo del SGBD se ha ralentizado considerablemente, ya que la comunidad ya no dispone del organismo para reaccionar rápidamente a los problemas y aplicar los cambios.
Cuando usar MySQL
- Operaciones distribuidas: El soporte de replicación de MySQL lo hace una gran opción para configuraciones de bases de datos distribuidas como arquitecturas primarias-secundarias o primarias-primarias.
- Sitios web y aplicaciones web: MySQL impulsa muchos sitios web y aplicaciones a través de Internet. Esto es, en gran parte, gracias a lo fácil que es instalar y configurar una base de datos MySQL, así como su velocidad y escalabilidad general a largo plazo.
- Crecimiento futuro esperado: El soporte de replicación de MySQL puede ayudar a facilitar la escalada horizontal. Además, es un proceso relativamente sencillo para actualizar a un producto comercial de MySQL, como MySQL Cluster, que admite las bases de datos fragmentadas (sharding) automático, otro proceso de escalamiento horizontal.
Cuando no usar MySQL
- El cumplimiento del SQL es necesario: Dado que MySQL no intenta implementar el estándar completo de SQL, esta herramienta no es completamente compatible con SQL. Si el cumplimiento completo o incluso casi completo de SQL es una necesidad para su caso de uso, es posible que desee utilizar un SGBD que cumpla más completamente con el estándar.
- Concurrencia y grandes volúmenes de datos: Aunque MySQL generalmente funciona bien con operaciones de lectura pesada, la lectura y escritura concurrentes pueden ser problemáticas. Si su aplicación tiene muchos usuarios que escriben datos en ella a la vez, otro SGBDR como PostgreSQL podría ser una mejor opción de base de datos.
PostgreSQL
PostgreSQL, también conocido como Postgres, se autoproclama como «la base de datos relacional de código abierto más avanzada del mundo». Fue creado con el objetivo de ser altamente extensible y cumplir con los estándares. PostgreSQL es una base de datos relacional de objetos, lo que significa que aunque es principalmente una base de datos relacional también incluye características – como la herencia de tablas y la sobrecarga de funciones – que se asocian más a menudo con las bases de datos de objetos.
Postgres es capaz de manejar eficientemente múltiples tareas al mismo tiempo, una característica conocida como concurrencia. Lo logra sin bloqueos de lectura gracias a su implementación de control de concurrencia mediante versiones múltiples (Multiversion concurrency control o MVCC), que asegura la atomicidad, consistencia, aislamiento y durabilidad de sus transacciones, también conocida como cumplimiento del ACID.
PostgreSQL no se utiliza tan ampliamente como MySQL, pero todavía hay una serie de herramientas y bibliotecas de terceros diseñadas para simplificar el trabajo con PostgreSQL, incluyendo pgAdmin y Postbird.
Tipos de datos admitidos por Postgres
Datos de tipo numérico
| Tipo de dato | Descripción |
|---|---|
bigint | Un entero con signo de 8 bytes. |
bigserial | Un entero con signo de 8 bytes que se incrementa una unidad de manera automática (autoincremental). |
double precision | Un número de coma flotante de doble precisión, de 8 bytes. |
integer | Un entero con signo de 4 bytes. |
numeric o decimal | Un número al cual se le puede asignar su precisión, recomendado en casos donde la exactitud es muy importante, tal como es el caso de los montos de monedas o divisas. |
real | Un número de coma flotante de doble precisión, de 4 bytes. |
smallint | Un entero con signo de 2 bytes. |
smallserial | Un entero con signo de 2 bytes que se incrementa una unidad de manera automática (autoincremental). |
serial | Un entero con signo de 4 bytes que se incrementa una unidad de manera automática (autoincremental). |
Datos de tipo cadena de texto
| Tipo de datos | Descripción |
|---|---|
character | Una cadena de texto con una longitud fija especificada. |
character varying o varchar | Una cadena de texto de longitud variable pero con un valor máximo asignado por nosotros. |
text | Una cadena de texto de longitud variable, sin valor máximo. |
Datos de tipo fecha y tiempo
| Tipo de dato | Descripción |
|---|---|
date | Una fecha calendario con el día, mes y año. |
interval | Un período de tiempo. |
time o time without time zone | Una hora del día, sin incluir la zona horaria. |
time with time zone | Una hora del día con zona horaria. |
timestamp o timestamp without time zone | Fecha y hora sin incluir la zona horaria. |
timestamp with time zone | Fecha y hora con zona horaria. |
Datos de tipo geométrico
| Tipo de dato | Descripción |
|---|---|
box | Una caja rectangular en un plano. |
circle | Un círculo en un plano. |
line | Una línea infinita en un plano. |
lseg | Un segmento de línea en un plano. |
path | Una ruta geométrica en un plano. |
point | Un punto geométrico en un plano. |
polygon | Una ruta geométrica cerada en un plano. |
Datos de tipo direcciones de red
| Tipo de dato | Descripción |
|---|---|
cidr | Una dirección de red, IPv4 o IPv6. |
host | Una dirección de anfitrión, IPv4 o IPv6. |
macaddr | Una dirección MAC. |
Datos de tipo cadena de texto binario
| Tipo de dato | Descripción |
|---|---|
bit | Una cadena de texto binaria de longitud fija. |
bit varying | Una cadena de texto binaria de longitud variable. |
Datos de tipo texto de búsqueda
| Tipo de dato | Descripción |
|---|---|
tsquery | Una consulta de búsqueda de texto. |
tsvector | Una consulta de búsqueda de documento. |
Datos de tipo JSON
| Tipo de dato | Descripción |
|---|---|
json | Dato tipo JSON en modo de texto. |
jsonb | Dato tipo JSON en modo binario. |
Otros tipos de datos
| Tipo de dato | Descripción |
|---|---|
boolean | Un valor booleano, representando ya sea verdadero true o falso false. |
bytea | Abreviatura de «matriz binaria» (byte array), para almecanar datos binarios. |
money | Para representar montos monetarios. |
pg_lsn | Un número de secuencia de registro PostgreSQL. |
txid_snapshot | Un identificador de captura de transacción a nivel de usuario. |
uuid | Un identificador único universal. |
xml | Datos en formato XML. |
Venatajas de Postgres
-
Conformidad con el SQL: Más que SQLite o MySQL, PostgreSQL apunta a adherirse estrechamente a los estándares de SQL. De acuerdo con la documentación oficial de PostgreSQL, PostgreSQL soporta 160 de las 179 características requeridas para el cumplimiento completo del núcleo de SQL:2011, además de una larga lista de características opcionales.
-
Código abierto y orientado a la comunidad: Un proyecto completamente de código abierto, el código fuente de PostgreSQL es desarrollado por una gran y dedicada comunidad. De manera similar, la comunidad Postgres mantiene y contribuye a numerosos recursos en línea que describen cómo trabajar con el SGBD, incluyendo la documentación oficial, el wiki de PostgreSQL y varios foros en línea.
-
Extensible: Los usuarios pueden extender PostgreSQL programáticamente y sobre la marcha a través de su operación dirigida por catálogo y su uso de carga dinámica. Uno puede designar un archivo de código objeto, como una biblioteca compartida, y PostgreSQL lo cargará según sea necesario.
Desventajas de Postgres
- Rendimiento de la memoria: para cada nueva conexión de cliente, PostgreSQL bifurca un nuevo proceso. A cada nuevo proceso se le asignan unos 10 MB de memoria, que pueden acumularse rápidamente para bases de datos con muchas conexiones. En consecuencia, para operaciones simples de lectura pesada, PostgreSQL es típicamente menos eficiente que otros SGBDR, como MySQL.
- Popularidad: Aunque se ha utilizado más ampliamente en los últimos años, PostgreSQL históricamente se ha quedado atrás de MySQL en términos de popularidad. Una consecuencia de esto es que todavía hay menos herramientas de terceros que pueden ayudar a administrar una base de datos PostgreSQL. Del mismo modo, no hay tantos administradores de bases de datos con experiencia en la administración de una base de datos Postgres en comparación con aquellos con experiencia en MySQL.
Cuando usar Postgres
- La integridad de los datos es importante: PostgreSQL cumple plenamente con el ACID desde 2001 e implementa un control cncurrente multiversión para asegurar que los datos sigan siendo consistentes, lo que lo convierte en una fuerte opción de SGBDR cuando la integridad de los datos es crítica.
- Integración con otras herramientas: PostgreSQL es compatible con una amplia gama de lenguajes y plataformas de programación. Esto significa que si alguna vez necesita migrar su base de datos a otro sistema operativo o integrarla con una herramienta específica, es probable que sea más fácil con una base de datos PostgreSQL que con otro SGBDR.
- Operaciones complejas: Postgres soporta planes de consulta que pueden aprovechar múltiples CPUs para responder a las consultas con mayor velocidad. Esto, junto con su fuerte soporte para múltiples escritores concurrentes, lo convierte en una gran opción para operaciones complejas como el almacenamiento de datos y el procesamiento de transacciones en línea.
Cuando no usar Postgres
- La velocidad es imprescindible: a expensas de la velocidad, PostgreSQL fue diseñado teniendo en cuenta la extensibilidad y la compatibilidad. Si su proyecto requiere las operaciones de lectura más rápidas posibles, PostgreSQL puede no ser la mejor opción de SGBDR.
- Configuraciones simples: debido a su gran conjunto de características y su fuerte adherencia al SQL estándar, Postgres puede ser excesivo para configuraciones simples de bases de datos. Para operaciones con mucha lectura en las que se requiere velocidad, MySQL suele ser una opción más práctica.
- Replicación compleja: aunque PostgreSQL proporciona un fuerte soporte para la replicación, sigue siendo una característica relativamente nueva y algunas configuraciones, como una arquitectura primaria-primaria, solo son posibles con extensiones. La replicación es una característica más madura en MySQL y muchos usuarios consideran que la replicación de MySQL es más fácil de implementar, particularmente para aquellos que carecen de la base de datos y la experiencia de administración del sistema requeridas.
Conclusión
Hoy en día, SQLite, MySQL y PostgreSQL son los tres sistemas de gestión de bases de datos relacionales de código abierto más populares del mundo. Cada uno tiene sus propias características y limitaciones, y sobresale en escenarios particulares. Hay bastantes variables en juego cuando se decide por un SGBDR, y la elección rara vez es tan simple como elegir el más rápido o el que tiene más características. La próxima vez que necesite una solución de base de datos relacional, asegúrese de investigar a fondo estas y otras herramientas para encontrar la que mejor se adapte a sus necesidades.
Si desea obtener más información sobre SQL y cómo utilizarlo para gestionar una base de datos relacional, le recomendamos que consulte nuestra hoja de referencia (en idioma portugués) «Cómo gestionar una base de datos SQL«. Por otro lado, si desea aprender sobre bases de datos no relacionales (o NoSQL), consulte nuestra «Comparación de sistemas de administración de bases de datos NoSQL».
Referencias
- DB-Engines Rankings
- SQLite Official Documentation
- SQLite Is Serverless
- Appropriate Uses For SQLite
- MySQL Official Documentation
- Comparing MySQL and Postgres 9.0 Replication
- PostgreSQL Official Documentation
- Has the time finally come for PostgreSQL?
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.- English language: This article is a translation from English into Spanish, published under license «Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0) », written by Ostezer and Mark Drake, published on line by the company for leasing virtual machines DigitalOcean. The tittle is «SQLite vs MySQL vs PostgreSQL: A Comparison Of Relational Database Management Systems» and we created a copy at Wayback Machine for prevent in future a broken link. This work is licensed under the mencioned license but, of course, in castilian language (AKA spanish): «Atribución-NoComercial-CompartirIgual 4.0 Internacional (CC BY-NC-SA 4.0) ».
Esta obra está bajo una Licencia Creative Commons Atribución-NoComercial-CompartirIgual 4.0 Internacional.- En castellano: Este artículo es una traducción del inglés al castellano, publicado bajo licencia (en idioma inglés) «Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0) » escrito por Ostezer y Mark Drake, publicado en línea por la empresa de alojamiento de máquinas virtuales DigitalOcean. El título original en idioma inglés es «SQLite vs MySQL vs PostgreSQL: A Comparison Of Relational Database Management Systems» y hemos creado una copia en Wayback Machine para prevenir un posible enlace roto a futuro.
El modelo de datos relacionales, que organiza los datos en tablas de filas y columnas, predomina en los instrumentos de gestión de bases de datos. Hoy en día existen otros modelos de datos, incluidos el NoSQL y el NewSQL, pero los sistemas de gestión de bases de datos relacionales (SGBDR) siguen siendo dominantes para el almacenamiento y la gestión de datos en todo el mundo.
En este artículo se comparan y contrastan tres de los RDBMS de código abierto más utilizados: SQLite, MySQL y PostgreSQL. Específicamente, explorará los tipos de datos que utiliza cada SGBDR, sus ventajas y desventajas, y las situaciones en las que se optimizan mejor.