Los 13 mejores software de base de datos de código abierto para su próximo proyecto

Los datos lo son todo. Y, por extensión, también lo son las bases de datos. Aquí hay algunas opciones fantásticas de código abierto para su próximo proyecto espectacular.

For a world dominated so long by database suits like Oracle and SQL Server, there seems to be an endless flurry of solutions now. One part of the reason is innovation fueled by Open Source — really talented developers wanting to scratch an itch and creating something that they can revel in.

La otra parte es el surgimiento de nuevos modelos comerciales, en los que las empresas mantienen una versión comunitaria de su producto para ganar participación y tracción al mismo tiempo que brindan una oferta comercial complementaria.

¿El resultado?

Más bases de datos de las que uno puede mantener. No hay una estadística oficial sobre esto, pero estoy bastante seguro de que tenemos más de cien opciones disponibles hoy si combina todo, desde bases de datos de objetos específicos de pila hasta proyectos no tan populares de universidades.

Sé; también me asusta. Demasiadas opciones, demasiada documentación para revisar, y una vida tan corta. 🙂

That’s why I decided to write this article, presenting ten of the best databases you can use to improve your solutions, whether building for yourself u otras personas.

Sin MySQL

Tenga en cuenta: esta lista no contendrá MySQL, aunque podría decirse que es la solución de base de datos de código abierto más popular que existe.

¿Por qué?

Simply because MySQL is everywhere — it’s what everyone learns first, it’s supported by virtually every CMS or framework out there, and it’s very, very good for most use cases. In other words, MySQL doesn’t need to be “discovered.” 🙂

Dicho esto, tenga en cuenta que las siguientes no son necesariamente alternativas a MySQL. En algunos casos, pueden ser, mientras que en otros, son una solución completamente diferente para una necesidad completamente diferente. No se preocupe, ya que hablaré sobre sus usos también.

Nota especial: compatibilidad

Before we begin, I also must mention that compatibility is something you need to keep in mind. If you have a project that, for whatever reason, supports only a particular database engine, your choices are pretty much shot through.

Por ejemplo, si utiliza WordPress, este artículo no le servirá de nada. 🙂 De manera similar, aquellos que ejecutan sitios estáticos en JAMStack no ganarán nada si buscan alternativas con demasiada seriedad.

It’s up to you to figure out the compatibility equation. However, if you have a blank slate and the architecture is up to you, here are some neat recommendations.

PostgreSQL

Si eres del país PHP (WordPress, Magento, Drupal, etc.), entonces PostgreSQL te sonará extraño. Sin embargo, este software de base de datos relacional existe desde 1997 y es la mejor opción en comunidades como Ruby, Python, Go, etc.

In fact, many developers eventually “graduate” to PostgreSQL for the features it offers or simply for stability. It’s hard to convince someone in a short write-up like this but think of PostgreSQL as a thoughtfully engineered product that never lets you down.

Hay muchos buenos Clientes SQL disponible para conectarse a la base de datos PostgreSQL para administración y desarrollo.

Características únicas

PostgreSQL has several fascinating features as compared to other relational databases (specifically, MySQL), such as:

• Tipos de datos integrados para matriz, rango, UUID, geolocalización, etc.
• Soporte nativo para almacenamiento de documentos (estilo JSON), XML y almacenamiento de valor clave (Hstore)
• Syncronoso y unsynchronous replication
• Scriptable en PL, Perl, Python y más
• Búsqueda de texto completo

My personal favorites are the geolocation engine (which takes away the pain when working with location-based apps — try finding all nearby points manually, and you’ll know what I mean) and support for arrays (many MySQL projects are undone for want of arrays, opting instead for the infamous comma-separated strings).

Cuándo usar PostgreSQL

PostgreSQL is always a better choice than any other relational database engine. That is, if you’re starting a new project and have been bitten by MySQL before, it’s a good time to consider PostgreSQL. I have friends who gave up battling MySQL’s mysterious transactional lock failures and moved on permanently. If you decide the same, you won’t be overreacting.

PostgreSQL también tiene una clara ventaja si necesita instalaciones NoSQL parciales para un modelo de datos híbrido. Dado que el almacenamiento de documentos y valores clave se admite de forma nativa, no es necesario buscar, instalar, aprender y mantener otra solución de base de datos.

Cuando no usa PostgreSQL

PostgreSQL doesn’t make sense when your data model isn’t relational and/or when you have very specific architectural requirements. For instance, consider Analytics, where new reports are constantly being created from existing data. Such systems are read-heavy and suffer when a strict schema is imposed on them. Sure, PostgreSQL has a document storage engine, but things start to fall apart when you’re dealing with large datasets.

En otras palabras, use siempre PostgreSQL a menos que sepa al 100% lo que está haciendo. 🙂

Mire este pequeño Curso de SQL y PostgreSQL para principiantes si está interesado en aprender más.

MariaDB

MariaDB era created as a replacement for MySQL by the same person who developed MySQL.

¿Confuso?

Well, actually, after MySQL was taken over by Oracle in 2010 (by acquiring Sun Microsystems, which, incidentally, is also how Oracle came to control Java), the creator of MySQL started a new open source project called MariaDB.

Why does all this boring detail matter, you ask? It’s because MariaDB was created from the same code base as that of MySQL (in the open-source world, this is known as “forking” an existing project). As a result, MariaDB is presented as a “drop-in” replacement for MySQL.

That is, if you’re using MySQL and want to migrate to MariaDB, the process is tan fácil que simplemente no lo vas a creer.

Unfortunately, such a migration is a one-way street. Going back from MariaDB to MySQL is not possible, and should you try to use force, permanent database corruption is ensured!

Las características únicas

While MariaDB is essentially a clone of MySQL, it’s not strictly true. Ever since the introduction of the database, the differences between the two have been growing. As of writing, adopting MariaDB needs to be a well-thought-through decision on your part. That said, there are plenty of new things going on in MariaDB that may help you make this transition:

• Truly free and open: Since there’s no single corporate entity controlling MariaDB, you can be free of sudden predatory licensing and other worries.
• Varias opciones más de motores de almacenamiento para necesidades especializadas: por ejemplo, el motor Spider para transacciones distribuidas; ColumnStore para almacenamiento masivo de datos; el motor ColumnStore para almacenamiento distribuido paralelo; y muchos muchos mas.
• Speed improvements over MySQL, especially due to the Aria storage engine for complex queries.
• Dynamic columns for different rows en una mesa
• Mejores capacidades de replicación (por ejemplo, replicación de múltiples fuentes)
• Varias funciones JSON
• Columnas virtuales

. . . Y muchos muchos mas. Es agotador mantenerse al día con todas las funciones de MariaDB. 🙂

Cuando usar MariaDB

Si desea un verdadero reemplazo de MySQL, debe usar MariaDB, ya que quieren permanecer en la curva de innovación y no planean regresar a MySQL nuevamente. Un caso de uso excelente es el uso de nuevos motores de almacenamiento en MariaDB para complementar el modelo de datos relacionales existente de su proyecto.

Cuando no usar MariaDB

La compatibilidad con MySQL es la única preocupación aquí. Dicho esto, se está volviendo un problema menor a medida que proyectos como WordPress, Joomla, Magento, etc., han comenzado a admitir MariaDB. Mi consejo sería no usar MariaDB para engañar a un CMS que no lo admite, ya que muchos trucos específicos de la base de datos bloquearán el sistema fácilmente.

Mira la diferencia entre MariaDB frente a MySQL y Guía de instalación de MariaDB.

Cucarachas

El equipo detrás de CockroachDB parece estar compuesto por masoquistas. Con un nombre de producto como ese, seguramente quieren poner todas las probabilidades en su contra y aún así ganar.

Bueno, no exactamente.

La idea detrás de "cucaracha" es que es un insecto construido para sobrevivir. Pase lo que pase: depredadores, inundaciones, oscuridad eterna, comida podrida, bombardeos, la cucaracha encuentra la manera de sobrevivir y multiplicarse.

The idea is that the team behind CockroachDB (composed of former Google engineers) was frustrated with the limitations of traditional SQL solutions when it comes to large scale. That’s because, historically, SQL solutions were supposed to be hosted on a single machine (data wasn’t that big). For a long time, there was no way to build a cluster of databases running SQL, which is why MongoDB captured so much attention.

Even when replication and clustering came out in MySQL, PostgreSQL, and MariaDB, it was painful at best. CoackroachDB wants to change that, bringing effortless sharding, clustering, and high availability to the world of SQL.

Cuándo usar CockroachDB

Cucarachas es el sueño del arquitecto de sistemas hecho realidad. Si jura por SQL y ha estado hirviendo a fuego lento con las capacidades de escalado de MongoDB, le encantará CockroachDB. Ahora puede configurar rápidamente un clúster, enviarle consultas y dormir tranquilo por la noche. 🙂

Cuando no usar CockroachDB

Better the devil you know than the one you don’t. By that, I mean, if your existing RDBMS is working well for you and you think you can manage the scaling pains it brings, stick with it. CockroachDB is a new product for all the genius involved, and you don’t want to be struggling against it later on. Another major reason is SQL compatibility — if you’re doing exotic SQL stuff and rely on it for critical things, CockroachDB will present too many edge cases for your liking.

De ahora en adelante, consideraremos soluciones de base de datos que no sean SQL (o NoSQL, como se le llama) para necesidades altamente especializadas.

casa de clics

¿Está buscando un sistema de base de datos OLAP rápido y de código abierto?

Ir por casa de clics.

It uses every hardware to its maximum potential to approach each query faster. The peak rendimiento de processing a query usually remains more than two terabytes each second. To avoid increased latency, reads are balanced automatically among the healthy replicas. 

It supports multi-master async replication, and you can deploy it across different data centers. As nodes are maintained equal, you can avoid even single failure points. The downtime of either a single node or the complete data center will never affect system availability in terms of writes and reads.

ClickHouse is very easy to use and simple. It streamlines data processing, puts all your data into a system in an organized manner, and is available instantly to build reports. Moreover, SQL dialect helps to express the result without using any non-standard API, which you can get in alternative systems. 

You can rely on this database management system to configure it as a distributed system that is located on separate nodes without failure points. Additionally, its security features are robust, including enterprise-grade security and fail-safe mechanisms in case of human errors.

ClickHouse can process queries faster compared to row-oriented systems having the same CPU capacity and I/O throughput. Its columnar data storage format helps keep more data inside RAM, resulting in shorter response times.

The total ownership cost can be reduced by commodity hardware having rotary disk drives rather than using NVMe/SSD without sacrificing latency for the queries. It strives for CPU efficiency, optimizes access to the disk drive, and minimizes data transfers. 

Furthermore, due to its feature-laced SQL database, you can efficiently process your query in no time, join co-located and distributed data, manage denormalized information efficiently, and more. ClickHouse scales horizontally y verticalally and adapts easily to perform on a single server or clusters with thousands of nodes.

Utilice ClickHouse para análisis web y de aplicaciones, telecomunicaciones, redes publicitarias, juegos en línea, IoT, inteligencia empresarial , finanzas, comercio electrónico, monitoreo y más. 

Se integraates con Hadoop, Postgres y MySQL.

Si no está listo para instalar y configurar un servidor, puede probar Kamatera que ofrece ClickHouse con un solo clic.

Neo4j

One of the most significant developments in the recent decade is connected data. The world around us is not partitioned into tables and rows y boxes — it’s one giant mess with everything connected to almost everything else.

Las redes sociales son un buen ejemplo, y construir un modelo de datos similar usando SQL o incluso bases de datos basadas en documentos es una pesadilla.

Eso es porque la estructura de datos ideal para estas soluciones es el gráfico, que es una bestia completamente diferente. Y para eso, necesita una base de datos gráfica como Neo4j.

The example above was taken directly from the Neo4j website and shows how university students are connected to their departments and courses. Such a data model is plain impossible with SQL, as it’ll be tough to avoid infinite loops and memory overruns.

Las características únicas

Bases de datos are unique in themselves, and Neo4j is pretty much the only option for working with graphs. As a result, whatever features it has are unique. 🙂

• Soporte para aplicaciones transaccionales y análisis de gráficos.
• Habilidades de transformación de datos para asimilar datos tabulares a gran escala en gráficos.
• Lenguaje de consulta especializado (Cypher) para consultar la base de datos de gráficos
• Funciones de visualización y descubrimiento

It’s a moot point to discuss when to use Neo4j and when not. If you need graph-based relationships between your data, you need Neo4j. 🙂

MongoDB

MongoDB was the first non-relational database to make big waves in the tech industry and continues to dominate a fair share of attention.

Unlike relational databases, MongoDB is a “document database,” which stores data in chunks, with related data clumped together in the same chunk. This is best understood by imagining an aggregation of JSON structures like this:

Here, unlike a table-based structure, the user’s contact details and access levels reside inside the same object. Fetching the user object fetches the associated data automatically, and there’s no concept of a join. Esto es una introducción más detallada a MongoDB.

Las características únicas

MongoDB has some serious (I almost want to write “kick-ass” to convey the impact, but it wouldn’t be proper on a public website, perhaps) features that have made several seasoned architects abandon the relational land forever:

• Un esquema flexible para casos de uso especializados / impredecibles.
• Ridículamente simple sharding y agrupación. Solo necesita configurar la configuración para un clúster y olvidarse de él.
• Agregar o eliminar un nodo de un clúster es muy sencillo.
• Distributed transactional locks. This feature was missing in the earlier versions but was eventually introducido.
• Está optimizado para escrituras muy rápidas, lo que lo hace muy adecuado para datos analíticos como sistema de almacenamiento en caché.

If I sound like a spokesperson for MongoDB, I apologize, but it’s hard to oversell the advantages of MongoDB. Sure, NoSQL data modeling is weird at first, and some never get the hang of it, but for many architects, it almost always wins out over a table-based schema.

Cuándo usar MongoDB

MongoDB es un gran puente cruzado del mundo estructurado y estricto de SQL al amorfo, casi confuso, de NoSQL. Se destaca en el desarrollo de prototipos, ya que simplemente no hay un esquema del que preocuparse y cuándo realmente Necesito escalar. Sí, puede usar un servicio SQL en la nube para deshacerse de los problemas de escalamiento de la base de datos, pero ¡es caro!

finalally, there are use cases where SQL-based solutions just won’t do. For instance, if you’re creating a product like Canva, where the user can create arbitrarily complex designs and be able to edit them later, good luck with a relational database!

Cuando no usar MongoDB

The complete lack of schema that MongoDB provides can work as a tar pit for those who don’t know what they’re doing. Data mismatch, dead data, empty fields that should not be empty — all this and much more is possible. MongoDB is essentially a “dumb” data store, and if you choose it, the application code has to take a lot of responsibility for maintaining data integrity.

Si es un desarrollador, encontrará esto útil.

RepensarDB

Como dice su nombre, RepensarDB “Replantea” la idea y las capacidades de una base de datos cuando se trata de aplicaciones en tiempo real.

When a database gets updated, there’s no way for the application to know. The accepted approach is for the app to fire off a notification as soon as there’s an update, which gets pushed to the front-end through a complex bridge (PHP -> Redis -> Node -> Socket.io is one example).

But what if the updates could be pushed directly from the database to the front-end?!

Sí, esa es la promesa de RethinkDB. Entonces, si está creando una verdadera aplicación en tiempo real (juego, mercado, análisis, etc.), vale la pena echarle un vistazo a Rethink DB.

Redis

Cuando se trata de bases de datos, es casi demasiado fácil pasar por alto la existencia de Redis. Eso es porque Redis es una base de datos en memoria y se usa principalmente en funciones de soporte como el almacenamiento en caché.

Aprendiendo esta base de datos is a ten-minute job (literally!), and it’s a simple key-value store that stores strings with an expiry time (which can be set to infinity, of course). What Redis loses in features it makes up for in utility and performance. Since it lives entirely in RAM, reads and writes are insanely fast (a few hundred thousand operations per second aren’t unheard of).

Redis also has a sophisticated pub-sub sistema, which makes this “database” twice as attracthe.

En otras palabras, si tiene un proyecto que podría beneficiarse del almacenamiento en caché o tiene algunos componentes distribuidos, Redis es la primera opción.

SQLite

Sí, prometí que habíamos terminado con las bases de datos relacionales, pero SQLite es demasiado lindo para ignorarlo.

SQLite es una biblioteca C liviana que proporcionó un motor de almacenamiento de base de datos relacional. Todo en esta base de datos vive en un solo archivo (con una extensión .sqlite) que puede colocar en cualquier lugar de su sistema de archivos. ¡Y eso es todo lo que necesitas para usarlo! Sí, no hay software de "servidor" para instalar ni servicio al que conectarse.

Caracteristicas utiles

Aunque SQLite es una alternativa ligera a una base de datos como MySQL, tiene un gran impacto. Algunas de sus impactantes características son:

• Soporte completo para transacciones, con COMMIT, ROLLBACK y BEGIN.
• Soporte para 32,000 columnas por tabla
• Soporte JSON
• Soporte JOIN de 64 vías
• Subconsultas, búsqueda de texto completo, etc.
• Tamaño máximo de la base de datos de 140 terabytes.
• Tamaño máximo de fila de 1 gigabyte.
• 35% más rápido que la E / S de archivos

Cuando usar SQLite

SQLite is an extremely specialized database that focuses on a no-nonsense, get-shit-done approach. If your app is relatively simple and you don’t want the hassle of a full-blown database, SQLite is a serious candidate. It makes particular sense for small- to mid-sized CMSs and demo applications.

Cuando no usa SQLite

While impressive, SQLite doesn’t cover all the features of standard SQL or your favorite database engine. Clustering, stored procedures, and scripting extensions are missing. Also, there’s no client to connect, query, and explore the database. Finally, as the application size grows, performance will degrade.

Cassandra

Si bien muchos proclaman que el final de Java está cerca, de vez en cuando, la comunidad lanza una bomba y silencia a los críticos. Cassandra Es uno de esos ejemplos.

Cassandra belongs to what’s known as the “columnar” family of databases. The storage abstraction in Cassandra is a column rather than a row. The idea here is to store all the data in a column physically together on the disk, minimizing seek time.

Las características únicas

Cassandra was designed with a specific use case in mind — dealing with write-heavy loads and zero tolerance for downtime. These become its unique selling points.

• Rendimiento de escritura extremadamente rápido. Cassandra es posiblemente la base de datos más rápida que existe cuando se trata de manejar cargas de escritura pesadas.
• Linear scalability. That is, you can keep adding as many nodes to a cluster as you want, and there will be a zero increase in complexity or brittleness of the cluster.
• Tolerancia de partición inigualable. Es decir, incluso si varios nodos de un clúster de Cassandra caen, la base de datos está diseñada para seguir funcionando sin pérdida de integridad.
• Mecanografía estática

Cuando usar Cassandra

Logging and analytics are two of the best use cases for Cassandra. But that’s not all — the sweet spot is when you need to handle really large sizes of data (Apple has a Cassandra deployment handling 400+ petabytes of data while at Netflix, it handles 1 trillion requests a day) with literally zero downtime. High availability is one of the hallmarks of Cassandra.

Cuando no usar Cassandra

El esquema de almacenamiento de columnas de Cassandra también tiene sus desventajas. El modelo de datos es bastante plano, y si necesita agregaciones, Cassandra se queda corto. Además, logra una alta disponibilidad sacrificando la consistencia (recuerde el teorema CAP para sistemas distribuidos), lo que lo hace menos adecuado para sistemas donde se necesita una alta precisión de lectura.

Escala de tiempo

Los nuevos desarrollos exigen nuevos tipos de bases de datos, y la Internet de las cosas (IoT) es uno de esos fenómenos. Una de las mejores bases de datos de código abierto para eso es Escala de tiempo.

La escala de tiempo es un tipo de lo que se llama una base de datos de "series de tiempo". Es diferente de una base de datos tradicional en que el tiempo es el eje principal de preocupación, y el análisis y la visualización de conjuntos de datos masivos es una prioridad principal. Las bases de datos de series de tiempo rara vez ven un cambio en los datos existentes; un ejemplo son las lecturas de temperatura enviadas por un sensor en un greenhouse — new data keeps getting accumulated every second, which is of interest for analytics and reporting.

Entonces, ¿por qué no usar solo una base de datos tradicional con un campo de marca de tiempo? Bueno, hay dos razones principales para eso:

• Las bases de datos de uso general no están optimizadas para trabajar con datos basados ​​en el tiempo. Para la misma cantidad de datos, una base de datos de propósito general será mucho más lenta.
• The database needs to handle massive amounts of data as new data keeps flowing in, and removing data or changing schema, later on is not an option.

Las características únicas

Timescale DB has some exciting features that set it apart from other databases in the same category:

• Está construido sobre PostgreSQL, posiblemente la mejor base de datos relacional de código abierto que existe. Si su proyecto ya está ejecutando PostgreSQL, Timescale se deslizará directamente.
• La consulta se realiza mediante la sintaxis SQL familiar, lo que reduce la curva de aprendizaje.
• Velocidades de escritura ridículamente rápidas: millones de inserciones por segundo no son desconocidas.
• Miles de millones de rows or petabytes of data — it’s no big deal for Timescale.
• Verdadera flexibilidad con esquema: elija entre relacional o sin esquema según sus necesidades.

No tiene mucho sentido hablar sobre cuándo usar o no usar Timescale DB. Si IoT es su dominio, o busca características de base de datos similares, vale la pena echarle un vistazo a Timescale.

CouchDB

CouchDB is a neat little database solution that sits quietly in a corner and has a small but dedicated following. It was created to deal with the problems of a network loss and eventual resolution of data, which happens to be a problem so messy that developers would instead switch jobs than deal with it.

esencialally, you can think of a CouchDB cluster as a distributed collection of nodes large and small, some of which are expected to be offline. As soon as a node comes online, it sends data back to the cluster, which is slowly and carefully digested, eventually becoming available to the entire cluster.

Las características únicas

CouchDB es una especie única cuando se trata de bases de datos.

• Offline-first data synccapacidades de ing
• Specialized versions for mobile and web browsers (PouchDB, CouchDB Lite, etc.)
• Fiabilidad probada en batalla y resistente a los choques
• Agrupación sencilla con almacenamiento de datos redundante

Cuándo usar CouchDB

CouchDB was built for offline tolerance and remains unmatched in this regard. A typical use case is mobile apps where a portion of your data resides on a CouchDB instance on the user’s phone (because that is where it was generated). The exciting thing is that you cannot rely on the user’s device to be connected all the time, which means the database has to be opportunistic and be ready to resolve conflicting updateslater on. This is achieved using the impressive Protocolo de replicación de sofá.

Cuando no usar CouchDB

Trying to use CouchDB outside of its intended use case will lead to disaster. It uses way much more storage than anything else out there, simply because it needs to maintain redundant copies of data and conflict resolution results. As a result, write speeds are also painfully slow. Finally, CouchDB is not suitable as a general-purpose schema engine, as it doesn’t play well with schema changes.

HurónDB

HurónDB es una plataforma innovadora de código abierto construida sobre Postgres como alternativa a MongoDB. MongoDB es la base de datos mejor soportada y más fácil de usar, lo que permite a los desarrolladores crear aplicaciones más rápido que las bases de datos relacionales.

However, MongoDB abandoned its Open-Source roots, changing Server-Side Public License and making it unusable for many Open Source and Commercial Projects; this is where FerretDB comes into the picture. With FerretDB, users can run the same MongoDB protocol queries without learning a new language or command.

FerretDB es una base de datos de documentos de código abierto con compatibilidad con MongoDB incorporada, al tiempo que permite que PostgreSQL y otros backends de bases de datos ejecuten cargas de trabajo de MongoDB; esto le permite usar la sintaxis y los comandos existentes de MongoDB con su base de datos almacenada en PostgreSQL.

PostgreSQL, on which FerretDB is built, is a robust open-source relational database management system (RDMS). It’s a low-cost option for creating scalable, enterprise-grade databases. PostgreSQL has all of the capabilities and features that a relational database needs. It stores data as structured objects with rows and columns, perfect for massive complex searches and transactions.

FerretDB es una base de datos de documentos que utiliza comandos, controladores y herramientas similares a MongoDB para almacenar datos.

Unlike relational databases, which specify the database structure using tables, rows, and columns, FerretDB saves the information as JSON documents, allowing for seamless integration with modern online and mobile apps.

La capacidad de FerretDB para realizar búsquedas rápidas y eficientes en enormes bases de datos es una de sus características más destacadas. Además, la plataforma es altamente adaptable, lo que le permite ajustarla a las necesidades de su organización.

Es una increíble solución de base de datos tanto para profesionales como para principiantes. Es un sistema completamente descentralizado. blockchain motor de búsqueda de aplicaciones.

Ferretdb es una sólida herramienta de administración de bases de datos que permite a los desarrolladores y administradores de bases de datos buscar, probar e implementar código.

Para Concluir

I had to leave out many interesting candidates like Riak, so this list is to be taken as a guide rather than a commandment. I hope I was able to achieve my goal with this article — present not just a collection of database software recommendations but also briefly discuss where and how they need to be used (and avoided!).

Si tiene curiosidad por aprender bases de datos, consulte Udemy para algunos cursos brillantes en línea.