¿Las tablas de transición/bases de datos de etapas son un antipatrón?

Question

Son tablas de etapas un antipatrón que se utiliza cuando rpc (como Java RMI o algún tipo de llamada de servicio web) o cola de mensajes (como JMS) sería una mejor solución, o hay problemas mejor atendidos por tablas intermedias ?

Para aclarar:

Con la organización de mesas me refiero a aquellos casos en los registros se añaden a una tabla o tablas mediante un proceso que luego es leído por y sobre la que actúa el segundo proceso o procesos. No me refiero a las tablas cuyas tablas están destinadas a reflejar el estado del final del intervalo (final del día, final del período de pago, etc.). En la mayoría de los casos, el esquema de las tablas de etapas imita fielmente un tipo de datos de aplicación, como el cliente o la cuenta.

Entre las posibles causas de este anti-patrón:

1) Unidad de Negocio de pared entre los titulares de los dos procesos impide proceso que escribe o lee de puesta en escena está modificando.

2) Baja la confianza en el proceso que escribe o lee de puesta en escena lleva a los desarrolladores usar la tabla para evitar la pérdida de datos "en caso de que algo falla"

3) La falta de conocimiento o DGAS (no dan una^% $ @) actitud

Answer 1

Las tablas de etapas, como usted describe, son una parte esencial de la mayoría de los entornos de BI o data warehouse. Podría argumentar que el rpc confiable/resistente haría el mismo trabajo, pero creo que sería incorrecto.

Al tirar de datos a una tabla de etapas, la está moviendo fuera del entorno de producción, posiblemente para hacer más cálculos, sumarios, volver a indexar, volver a escribir, etc., la mayoría de estos se logran 'en base de datos'. Reemplazando esto con un RPC, está moviendo el código y la CPU pasa de la base de datos a un servidor de aplicaciones sin ningún beneficio real. Por ejemplo, un servidor de aplicaciones tiene muchas más posibilidades de bloquearse: no puede (fácilmente) retrotraer un RPC.

Por supuesto que hay muchas maneras de mover datos de manera confiable entre sistemas, las tablas de etapas son uno de los más fáciles, más efectivos, confiables y en términos de desarrollo más económicos, no siempre significa que sean el enfoque correcto. pero más a menudo que no.

Answer 2

El único momento real en el que he visto esto es por razones de informes cuando las tablas desnormalizadas se usan para almacenar datos mientras se genera un informe. No creo que sea un problema para ese uso.

Answer 3

Mi primera respuesta es sí, pero es principalmente debido a mi situación: la suya puede ser diferente. Tenemos un sistema donde la información relativamente sensible al tiempo debe pasar de un componente de comando a un componente de receptor. La información del comando se coloca en una tabla de la base de datos y luego el receptor sondea la tabla en busca de actualizaciones. Esto es horrible Lo hicieron para que hubiera un registro de los comandos en la base de datos, pero termina haciendo que el comando real tome para siempre y el desacoplamiento a veces hace que el receptor no esté sincronizado con la base de datos.

Prefiero ver un EMS (como JMS) transmitir el mensaje a un tema que escuchan el receptor y un insertador de base de datos, o una cola de comandante a receptor, y luego el receptor notificar a un oyente de estado para poner su estado en la base de datos.

No veo la hora de arreglar ese código.

Answer 4

¿Por qué serían un antipatrón? Las tablas de etapas son increíblemente útiles para desacoplar un servicio receptor de un servicio de procesamiento.Cuando dos de estos servicios están desacoplados, usted es mucho más resistente a los errores de procesamiento y de red ya que todos los mensajes se almacenan en la tabla de etapas.