¿Qué base de datos debo usar?

No soy un experto en bases de datos, así que tome esta respuesta con una pizca de sal. Sus elecciones son:

  1. Un RDBMS basado en cliente-servidor, como MySQL, MSSQL, Oracle, PostgreSQL, etc. Son sólidos, en uso de producción durante mucho tiempo, pero necesitan configuración y administración. Son versátiles: pueden administrar múltiples bases de datos desde una sola instancia del servidor. Se puede ampliar agrupando. Apoyarán la redundancia.
  2. Una base de datos SQL basada en archivos, como SQLite 3. No necesitan mucha configuración o administración. Trabaja satisfactoriamente para bases de datos pequeñas. Un archivo puede almacenar una base de datos. En realidad, son bibliotecas con una API y se incrustan en su aplicación. Fácil de usar, pero solo para proyectos pequeños. Pero puede ser necesario para dispositivos móviles. Hay otros similares a SQLite: Berkeley DB. No admiten redundancia o ampliación de escala.
  3. No hay bases de datos SQL ni bases de datos de documentos, como MongoDB. Tienen un esquema flexible, directamente mapeado a estructuras de datos (como diccionarios) en lenguajes de programación. Soporta redundancia y escala bien. Son el nuevo chico de la cuadra.

Con los dos primeros, los programadores usan directamente SQL o capas de abstracción:

DAL (Capa de abstracción de la base de datos) hace que el programa sea independiente de la base de datos real que utilizará el programa. Es decir, puede cambiar el servidor de base de datos back-end sin modificar su programa. Pero el programa tendrá sentencias SQL incrustadas en llamadas a funciones.

ORM (Object Relational Manager) hace que el programa sea independiente tanto de la base de datos del backend como de evitar sentencias SQL en llamadas a funciones. Se crea un conjunto de objetos y métodos que reflejan las tablas y relaciones en la base de datos y se accede a la base de datos a través de los objetos y sus métodos. El patrón de diseño común para esto es el ActiveRecord, y es implementado por varias bibliotecas en muchos lenguajes de programación.

A los efectos de DAL y ORM, todos los RDBMS, basados ​​en servidor o en archivo, parecen iguales. Las bases de datos NoSQL no necesitan ORM especiales (en lo que respecta a mi conocimiento limitado, corríjame si me equivoco), esto está integrado en el diseño de las bases de datos NoSQL.

A2A. Al principio, preferiría MySQL, simplemente porque su curva de aprendizaje es muy baja y es muy fácil de instalar y configurar. En su etapa, progresar lo ayudará a comprender mejor sus necesidades.

Debería poder escribir su código de una manera independiente de la base de datos, de modo que el cambio a una base de datos diferente no incurra en un refactor de código significativo. Si encuentra que MySQL es insuficiente (poco probable), para entonces debería haber acumulado suficiente conocimiento para poder cambiar sin problemas a PostgreSQL.

Bah.

Todo se reduce a esto; ¿Sabes cuáles serán tus consultas? ¿Sabes cuál sería la estructura de tu tabla en un entorno relacional?

Si sabe cómo serán sus consultas (sus operaciones CRUD en los datos), comience con MongoDB. Si no lo sabe y no puede pensarlo, comience con MySQL. Luego ve a buscar una buena estructura de tabla.

Sea lo que sea que elijas, no te quedarás atrapado. Simplemente elija algo y asegúrese de poner todas sus llamadas a la base de datos en un contenedor para que pueda reescribir el contenedor para un nuevo dbms.

No estás en la etapa en la que sabes lo suficiente como para elegir la arquitectura final, IMO. Está construyendo un prototipo y probablemente descubrirá que lo que elija tiene un problema del que desea migrar.

Los tres funcionan. Los tres pueden hacer el trabajo. Personalmente, creo que si vas a alojar en una nube, es mejor que tengas a MongoDB como iniciador, pero es posible que tengas buenas razones para cavar para no usar eso.

Sugeriría que vaya con una base de datos en la que tenga competencia. Mysql es bueno y escala muy bien. De hecho, preferiría mysql sobre mongodb. Postgresql tiene una curva de aprendizaje empinada pero es mucho más avanzada que mysql.

Te sugiero que elijas postgresql, si tienes un dba que pueda manejar las complejidades de postgresql, ve con mysql.

si sus datos no son enormes, recomendaré MySQL / MySQLi si cree que su proyecto generará el problema de disponibilidad que MongoDB