Pregunta

En los viejos días hemos utilizado para acceder a la base de datos a través de procedimientos almacenados.Ellos fueron vistos como `el mejor' manera de manejar los datos.Guardamos los datos en la base de datos, y cualquier lenguaje/plataforma puede acceder a él a través de JDBC/ODBC/etc.

Sin embargo, en los últimos años de tiempo de ejecución de reflexión meta-datos de almacenamiento basado en la recuperación de mecanismos tales como la Hibernación/DataNucleus se han vuelto populares.Inicialmente estábamos preocupados de que había de ser lento debido a los pasos adicionales involucrados (reflexión es caro) y cómo recuperar datos innecesarios (el objeto) cuando todo lo que necesitamos es un campo.

Estoy empezando a planear un gran almacenamiento de datos proyecto que utiliza J2EE, pero estoy un poco insegura de si ir para Procedimientos Almacenados o JDO/JPA y similares.Recientemente, he estado trabajando con Hibernate, y para ser honesto, no echo de menos escribir CRUD procedimientos almacenados!

Básicamente se reduce a:

Los procedimientos almacenados
+ Puede ser optimizado en el servidor (aunque sólo las consultas)
- No va a haber más de un millar de procedimientos almacenados:agregar, eliminar, actualizar, getById, etc, para cada tabla.

JDO
+ No le voy a dedicar los próximos meses a la escritura de parámetros.add("@firstNames", cliente.getFirstName());...
- Será más lento que el SPs (pero la mayoría del apoyo de paginación)

¿Qué haría usted gordas en mi situación.En este caso creo que es un mucho de todo.

Gracias,

Juan

No hay solución correcta

Otros consejos

"JDO - Será más lento que el SPs (pero la mayoría del apoyo de paginación)"

Esta suposición a menudo es falso.No hay ninguna razón para SP ser especialmente rápido.He hecho algunas mediciones y no eres más rápido que el código fuera de la base de datos.

Un almacén de datos se caracteriza por insertar-sólo para cargas de larga duración SELECT...GROUP BY... las consultas.

No estás escribiendo OLTP de procesamiento de transacciones.No estás usando 3NF como una manera de prevenir la actualización de anomalías en actualizar/eliminar transacciones.

Puesto que usted está haciendo inserciones masivas, un SP sin duda será más lento que el de una carga masiva de utilidad.A granel cargadores son a menudo multi-hilo y se consume todos los recursos de CPU disponibles.El SP es parte de la base de datos y sólo pueden compartir limitada DB recursos.

Puesto que usted está haciendo en su mayoría SELECT GROUP BY, un SP no ayuda mucho en esto, tampoco.La instrucción SELECT no se benefician de estar envuelto en un procedimiento.

Usted no los necesita.Ellos no ayudan.

Usted puede fácilmente un punto de referencia de carga masiva y una consulta para demostrar que la SP no están ayudando.

Rod Johnson en su "J2EE Diseño y Desarrollo", escribió un claro análisis sobre ORM/StoredProcedures.Él dijo que

Los procedimientos almacenados sólo debe ser utilizado en una J2EE sistema para realizar operaciones que siempre se utilizará la base de datos fuertemente, independientemente de si están implementados en la base de datos o en el código Java que intercambia una gran cantidad de datos con la base de datos.

Como usted está planeando la implementación de un datawarehouse, creo que los procedimientos almacenados enfoque es la elección correcta.

Me gustaría sugerir el uso de los metadatos para generar las secuencias de comandos se utiliza para la carga en el almacén de datos.Esto le permite obtener beneficios en el rendimiento del uso especializado de carga de herramientas y quizás de procedimientos almacenados (si estás usando una lo suficientemente antigua base de datos).También, usted probablemente va a terminar en las manos de codificación, al menos, algunos de SQL.Tener tu secuencias de comandos genéricos hecho almacenados procs le permiten programar todos ellos de la misma manera y no tener que preocuparse de cambiar la forma en que se invoca cuando la reescritura de algunos genera código para que funcione mejor.

Como para la obtención de los datos, si lo que estás construyendo en J2EE es una herramienta de información, entonces usted puede ser mejor usar JDO.Mientras yo no estoy muy familiarizado con la presentación de informes lado de las cosas, uno de los beneficios que puedo ver es que será más fácil para permitir a los usuarios finales para hacer informes personalizados que no prevé de antemano (aunque todavía tienes que tener ciertos límites en lo que puede hacer para que no se tome la base de datos en el proceso).

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top