Estructura de BD

Ya subí una propuesta de estructura (incompleta todavía) al repositorio de código. Está hecho para PostgreSQL pero seguro con un par de modificaciones pueden hacer una versión que corra en su base de datos favorita. Aviso de esto para que le echen un ojo y pongan aquí correcciones, sugerencias, etc.

Yo me inclino hacia PostgreSQL porque ya lo he usado en ambientes de producción donde se realizan cientos de miles de transacciones diarias, y una cantidad igual o mayor de consultas, y ha respondido bastante bien. Pero igual puede ser MySQL, creo que serían las dos opciones si realmente estamos haciendo un sistema en software libre.

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de Nopalin

jeje

Yo también he usado postgresql en ambientes de producción y puedo asegurar que trabaja bien, pero quiero llevar la contra, no han pensando en usar H2 database? la he utilizado para algunos sistemas no tan grandes pero en general ha respondido bien, incluso anda rondando por ahi un dialect para poder usarlo con hibernate.

Imagen de benek

MySQL

Me inclino hacia MySQL por una simple razón: El servidor de javaMéxico ya tiene esta instalación y el soporte en caso de actualizaciones lo provee el DataCenter.

Sería mucho rollo meternos en la instalación de una nueva BD, configuración y actualización/mantenimiento periódicos de la misma.

Imagen de Nopalin

H2 es puro java

pues con H2 database no habria tanto rollo, esta 100% hecha en java y la actualización se realiza reemplazando un simple jar, además de que los backups son más simples jeje y se puede configurar para ejecución en memoria para los testcase

Imagen de ezamudio

H2

Puedes usar H2 para pruebas pero para producción no es nada más de reemplazar un jar, está el respaldo de datos, monitoreo, etc. que en el caso de MySQL ya dijo benek que lo hace el DataCenter. Son razones de peso, ni modo no es mi hit pero pues usaremos MySQL en producción. En todo caso estaría bueno que cada quien sus pruebas las haga con lo que quiera y así aseguramos que haya compatibilidad, cosa que puede ser muy importante para tener siempre la compatibilidad con otras bases de datos.

Imagen de 1a1iux

el repositorio de código?

Hola @ezamudio,

En dónde está el repositorio de código de comentas? quisiera darla una revisadita a la propuesta de base de datos.

Se puede ?

Sale y vale
Byte

Imagen de ezamudio

Mercurial

http://code.google.com/p/javamexico/

También hay uno en SVN pero vamos a usar Mercurial

Imagen de benek

Push

No me había fijado que en los DVCS como Mercurial aparte de dar Commit hay que hacer Push al repositorio, así que no se veía el .sql de la propuesta de ezamudio que subí, pero ya está disponible.

Javier Ramírez Jr.

Saludos!

He estado revisando el proyecto. Ya tengo instalado mercurial, y ya tengo el workspace configurado en eclipse.

Ahora el problema que tengo es a la hora de crear ls BD, me marca lo siguiente:

ERROR: error de sintaxis en o cerca de «ON»
LINE 30: uid INTEGER REFERENCES usuario(uid) NOT NULL ON DELETE CASC...
^

********** Error **********

ERROR: error de sintaxis en o cerca de «ON»
SQL state: 42601
Character: 758

Estoy utilizando la última versión de PostreSQL con pgAdmin III y el error lo muestra cuando quiero ejecutar el script de la BD.

Imagen de Nopalin

Por éste mismo error, creo

Por éste mismo error, creo que se deberia estandar a una bd tanto para producción como para desarrollo y los testcase, por que aunque el SQL es un estandar, las implementaciones no lo son del todo.

Imagen de ezamudio

Sintaxis

He corregido la sintaxis de varias tablas. Por el momento solamente puedo garantizarte que funcionan bien los scripts para las tablas del módulo de preguntas y de foros, así como las más básicas de usuarios (o sea la tabla Usuario).

La sintaxis la hice mal y luego fui corrigiendo en donde obtuve esos errores. Es realmente:

uid INTEGER NOT NULL REFERENCES usuario(uid) ON DELETE CASCADE

es decir primero van las restricciones (NOT NULL) y luego las llaves foráneas o referencias a otras tablas.

Imagen de ezamudio

Estándar

El script de base de datos se llama tablas_postgresql_v1.sql precisamente porque está pensando para que funcione en postgres. Me parece que Benek iba a modificar el script para que funcione en Oracle y después alguien podrá modificarlo para que funcione en MySQL. Incluso alguien puede crear un programa que tome las clases de entidades y a partir de las mismas se generen las tablas en cualquier base de datos, cambiando el driver de JDBC, solamente faltaría meter más anotaciones de JPA para definir bien los tipos en base de datos, longitudes, etc.

Imagen de benek

Re: Estándar.

Creo que será mejor, más rápido y más seguro hacerlo como dices, una app que obtenga el modelo de las tablas en postgre y luego switchear el driver y configuración para que las cree en el otro RDBMS.

Pero entonces, tendré que montar Postgre primero y volcar ahí el script. Por qué no generas un dump de la estructura y con ese la levanto, sería más fácil para ti en lugar de ir corrigiendo sintaxis no?

Saludos.

Javier Ramírez Jr.

Imagen de ezamudio

No

Eso no es lo que dije. Lo que digo es que (hasta donde tengo entendido) se puede hacer un programa que a partir de las clases de entidades, con Hibernate, se crean las tablas en la base de datos que le digas (configurando el JDBC y supongo que la fábrica de sesiones). De hecho creo que el programa viene con Hibernate pero la verdad no me he metido a verlo.

No necesitas un dump de la estructura porque lo que tengo en postgres (de estructura) fue generado a partir del script que está en mercurial (y no tiene cambios que no haya subido ya).