¿Qué base de datos debo usar para crear mi aplicación web y móvil? Desarrollador de registros, desarrollo de aplicaciones

Entre PostgreSQL y MySQL, generalmente no hay una buena razón para usar MySQL sobre PostgreSQL, así que eliminemos eso de la lista.

SQLite3 es fantástico si desea una base de datos incrustada en una situación en la que tiene recursos limitados o necesita una experiencia de instalación perfecta para el usuario. SQLite es la base de datos estándar en aplicaciones móviles en Android e iOS (desde el iPod original) e incluso está incrustado en algunos navegadores web como WebSQL (aunque está en desuso ya que la gente de Chrome quería que el estándar se basara en el Implementación de SQLite, mientras que la gente de Mozilla pensó que esta era una forma ridícula de definir estándares).

Como mencionó las aplicaciones web, no debería usar SQLite. Requiere bloquear el acceso al archivo de la base de datos para cada escritura, y dado que se ejecuta dentro del proceso de su aplicación, eso significa que solo puede tener un proceso ejecutándose con acceso de escritura a la base de datos (aunque varios subprocesos están bien). Python tiene un bloqueo de intérprete global, lo que significa que puede usar efectivamente solo un núcleo en una CPU de varios núcleos a menos que ejecute múltiples procesos, lo que no puede porque SQLite no lo admite. Entonces: no use SQLite si está creando aplicaciones web en Python.

Lo que nos deja PostgreSQL y MongoDB.

PostgreSQL, como todas las bases de datos SQL (incluido SQLite), es una base de datos relacional. Se especializa en el seguimiento de las relaciones entre datos y en ayudarlo a recuperar algo si sabe algo relacionado con él.

Por ejemplo, si tiene dos tablas de base de datos, diga “Usuarios” para todos los usuarios y “Publicaciones” para todas las publicaciones realizadas por un usuario determinado, siendo “Posts.user_id” una referencia de clave externa para “Usuario”. id “, tiene un esquema en el que una publicación tiene un solo usuario y, como corolario, un usuario puede tener muchas publicaciones (dado que los propios usuarios no definen ninguna relación con las publicaciones, la relación es de la otra dirección). SQL hace que sea realmente fácil trabajar con tales relaciones. Puede decir “dado un usuario, consígame todas las publicaciones que hagan referencia a este usuario” o “dada esta publicación, consígame el usuario referido”.

Todas las bases de datos SQL pueden hacer consultas relacionales como esta, pero PostgreSQL es realmente muy bueno en esto. Sin embargo, existe un caso de uso avanzado para el que PostgreSQL no es tan bueno para: gráficos. Llegaremos a eso en un minuto.

La relación de usuarios y publicaciones anterior es un ejemplo de una relación de “uno a muchos” (o “muchos a uno”, según el lado desde el que esté mirando). Hay algo más llamado una relación de “muchos a muchos” que es básicamente un combo de “muchos a uno + uno a muchos”. En nuestro ejemplo hipotético de usuarios y publicaciones, si quisiéramos hacer posible que una publicación tenga más de un usuario, lo haríamos así: “Usuarios Publicaciones” donde esta nueva tabla “Usuarios_Publicaciones” tiene exactamente dos columnas, una referencia de clave externa a una fila en Usuarios, otra referencia de clave externa a una fila en Publicaciones. Para cada combinación única de Usuario y Publicación, puede agregar otra fila en la tabla Users_Posts que vincula ese usuario y publicación.

Aquí hay una situación muy común en la que necesita un modelo de este tipo: mapeo de películas y sus actores. Tiene una tabla para películas y actores, y una tabla de unión de “muchos a muchos” que los une a ambos.

Digamos que quiere saber en qué películas aparecieron los actores A y B. Eso es fácil: “SELECCIONAR * DESDE Películas DONDE ENTRAR (SELECCIONAR películas_id DESDE Películas_Actores DONDE ENTRAR actores_id (A, B))”.

¿Ves lo que hicimos? Esta es una consulta anidada. Comenzando desde el interior, primero solicitamos todos los ID de película en la tabla de unión que presentan a los actores A o B, luego solicitamos todos los detalles de la tabla de Películas donde la identificación de la película está en los resultados de la consulta anterior.

Ahora, ¿qué pasa si tienes una situación en la que A y B nunca han aparecido juntos en una película, pero quieres saber si tienen co-actores comunes? Esto es como LinkedIn o Facebook, donde estás mirando el perfil de alguien con quien no eres amigo, pero LinkedIn o Facebook te dicen que tienes amigos comunes. Este es un patrón de búsqueda de gráficos y es el tema de un tipo de base de datos completamente diferente llamado, apropiadamente, una base de datos de gráficos . Busque Neo4j para ver un ejemplo. Aunque los datos de gráficos se pueden modelar usando una base de datos relacional como PostgreSQL, es mejor usar algo especializado como Neo4j.

Y finalmente, MongoDB. ¿Para qué es esto? MongoDB no es una base de datos gráfica, ni siquiera una base de datos relacional . Al igual que CouchDB, es una base de datos de documentos y representa el otro extremo de la escala. ¿Qué sucede si desea almacenar todos los detalles de una película en un solo lugar y no está interesado en poder hacer una referencia cruzada de los datos? Las bases de datos relacionales quieren que “normalice” sus datos almacenando cada pequeño detalle en una tabla separada, pero le resulta molesto. Solo desea almacenar sus datos en un solo lugar sin tener que pensar demasiado. Todavía está descubriendo qué datos desea almacenar, por lo que por ahora solo desea volcarlos en algún lugar y preocuparse por consultarlos más adelante. Para eso son exactamente las bases de datos de documentos y MongoDB es el rey de esa colina.

PostgreSQL introdujo un tipo de datos JSON en la versión 9.2 y un tipo JSONB más eficiente en 9.4 (la versión actual), por lo que si tiene una combinación de datos relacionales y de documentos (que es muy probable), es posible que desee seguir con PostgreSQL en sí (consulte ¿Qué hay de nuevo en PostgreSQL 9.4).

Espero que ayude.