mysql derby

Derby o MySQL o...?



(2)

¿Para qué tipo de requisitos elegiría Apache Derby (o Java DB) sobre MySQL (o viceversa)? Miré a mi alrededor y la gente simplemente comparó los dos, pero nadie habla sobre cuándo considerar cada uno. Estoy desarrollando una aplicación basada en web usando Glassfish + Java / Restlet + MySQL.

Espero alrededor de 100-200 usuarios para este sistema con una carga de alrededor de 30-50 usuarios simultáneos en un momento dado, en su mayoría.

Me pidieron que mirara a Derby si deseo que la aplicación web se pueda descargar / distribuir. ¿Pero es esa la única razón por la que lo usaría? ¿Es adecuado para aplicaciones web? ¿Alguien lo ha usado? ¿Cuál ha sido tu experiencia y cuándo eliges una sobre la otra? (La mayoría de las discusiones sobre la comparación son anteriores a MySQL v5 cuando no tenía soporte para procedimientos almacenados, desencadenadores, etc., pero ese ya no es el caso).

Puedo entender un modelo de servidor de base de datos independiente con un servidor web que envía las solicitudes, pero ¿cómo cambia este modelo con una base de datos incorporada? ¿O es una opción predeterminada usar Derby en la configuración de red?


¿Por qué Derby y MySQL son los únicos RDMBS que consideras? Si dices Derby , deberías revisar HSQLDB , H2 , SQLite también. Si dices MySQL , deberías revisar Postgres también (que tiene muchas más funciones).

Esto es solo para nombrar algunos RDBMS gratuitos. Por supuesto, como ya lo dijo Charlie, hay muchos otros y muchas razones para ir de cualquier manera. Echa un vistazo a esta página de comparación (IMO excelente) en Wikipedia, donde encontrarás ventajas y limitaciones de cualquier RDBMS:

http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems

En lo que respecta a su requerimiento de que su aplicación web sea "descargable", por supuesto, puede incrustar un RDBMS (cualquiera de Derby, H2, HSQLDB) en su aplicación web. Pero también puede hacer que su MySQL o Postgres o cualquier integración sea configurable y dar instrucciones a los descargadores sobre cómo configurar su aplicación web. Después de todo, cuando usa un DataSource configurado para contenedor para su aplicación web, esta configuración se puede hacer fácilmente.

Ahora, incluso si piensa que podría ser más fácil para usted desarrollar su aplicación web con una base de datos integrada, siempre debe pensar un paso adelante. Preguntas como:

  • ¿Podrá conectarse directamente a esa base de datos para corregir fácilmente las inconsistencias de los datos? (Nos pasará a todos)
  • ¿Podrás alterar el esquema fácilmente?
  • ¿Podrá hacer una copia de seguridad de sus datos fácilmente?
  • etc etc ... hay más preguntas de mantenimiento, también

Dado que sus comentarios sugieren que sus datos aumentan con el tiempo y deberían persistir, no elegiría una versión incorporada, pero mantendría los datos separados de la aplicación. Tenga en cuenta que esto no excluye a Derby del diseño de su aplicación. Solo significa que tendrías que ejecutar Derby como un servidor independiente.


Los requisitos que marcarán la diferencia son los llamados requisitos "no funcionales": capacidad, confiabilidad, rendimiento (y tiempo de respuesta), disponibilidad y seguridad; esto junto con los problemas propios del software, como la facilidad con que está disponible, lo difícil que será mantener el software basado en él, etc.

Oracle es muy rápido, muy robusto, muy bien soportado y muy caro.

MySQL es una buena opción general con mucho uso. Puede configurarse para una alta disponibilidad y confiabilidad (a través de la creación de reflejo y maestro-esclavo), es bien conocido por muchos programadores y se integra bien en una gran cantidad de software de plataforma como Grails, Rails y JBoss.

Derby es bueno porque es muy independiente de la plataforma y mucha gente lee Java fácilmente.

SQLite es rápido, ligero y más o menos nativo en Mac.

... y así.

Primero, averigüe qué requisitos no funcionales son importantes, luego elija un DBMS.

Actualizar

Bien, siguiendo tu comentario.

Con esos números, permítame preguntar primero ¿por qué un RDBMS separado? Son 1000 filas: considere simplemente almacenarlas en la memoria, por ejemplo, en una colección de Colecciones que serialice.

Si realmente necesita una base de datos, diga porque está usando Rails, entonces no está desafiando NINGÚN RDBMS, puede ser difícil elegir porque está en un dominio donde todas las opciones son perfectamente buenas. Si es así, elija el que sea más fácil de usar y más fácil de admitir, que probablemente sea ​​MySQL, pero no es cierto, solo porque todos lo usan.