Cómo generar datos de prueba para un algoritmo "agrupar por datos de otras filas"

Question

ACTUALIZACIÓN: Estoy buscando una técnica para calcular datos para todos los casos límite de mi algoritmo (o algoritmo arbitrario para el caso).
Lo que intenté hasta ahora es solo pensar en lo que podrían ser casos límite + producir algunos datos "aleatorios", pero no sé cómo puedo estar más seguro de que no me perderé algo que los usuarios reales serán capaces de echar a perder ..

quiero comprobar que no se perdió algo importante en mi algoritmo y que no sé cómo generar datos de prueba para cubrir todas las situaciones posibles:

El tarea consiste en informe instantáneas de los datos para cada Event_Date, pero haga una fila separada para las ediciones que pueden pertenecer al siguiente Event_Date - véase el Grupo 2) en la entrada y salida de Ilustración de los datos:

Mi algoritmo:

1. hacer una lista de event_date s y calcular next_event_date s para ellos
2. une los resultados al main_audit_table y calcule el mayor transaction_id para cada instantánea (Grupos 1-4 en mi dibujo ción) - agrupadas por id, event_date y de 2 opciones en función de si transaction_date < next_event_date es verdad o no
3. unirse main_audit_table a los resultados para obtener los otros datos del mismo transaction_id
4. unirse costs_audit_table a los resultados - utilizar el mayor transaction_id que es menor que el resultado de transaction_id

Mi pregunta (s):

• ¿Cómo puedo generar datos de prueba que cubran todos los escenarios posibles, así que sé que tengo el algoritmo correcto?
• ¿Puedes ver algún error en la lógica de mi algoritmo?
• ¿Hay un foro mejor para este tipo de preguntas?

Mi código (que tiene que ser probado):

select 
    snapshots.id, 
    snapshots.event_date, 
    main.event, 
    main.transaction_date as last_change, 
    costs.costs as costs_2012 
    from (
    --snapshots that return correct transaction ids grouped by event_date 
    select 
     main_grp.id, 
     main_grp.event_date, 
     max(main_grp.transaction_id) main_transaction_id, 
     max(costs_grp.transaction_id) costs_transaction_id 
    from main_audit_table main_grp 
    join (
     --list of all event_dates and their next_event_dates 
     select 
     id, 
     event_date, 
     coalesce(lead(event_date) over (partition by id order by event_date), 
       '1.1.2099') next_event_date 
     from main_audit_table 
     group by main_grp.id, main_grp.event_date 
    ) list on list.id = main_grp.id and list.event_date = main_grp.event_date 
    left join costs_audit_table costs_grp 
     on costs_grp.id = main_grp.id and 
     costs_grp.year = 2012 and 
     costs_grp.transaction_id <= main_grp.transaction_id 
    group by 
     main_grp.id, 
     main_grp.event_date, 
     case when main_grp.transaction_date < list.next_event_date 
      then 1 
      else 0 end 
) snapshots 
    join main_audit_table main 
    on main.id = snapshots.id and 
     main.transaction_id = snapshots.main_transaction_id 
    left join costs_audit_table costs 
    on costs.id = snapshots.id and 
     costs.transaction_id = snapshots.costs_transaction_id 

Answer 1

expresiones de tabla común (CTE) no sólo son una buena manera de enterrar a la complejidad y reducir la duplicación de fragmentos SQL más largas, pero también es una forma fácil de representar los datos de prueba como si provinieran de una tabla permanente. Por lo menos, los CTE enfocarán los principales componentes de su consulta en la parte superior, lo que le permitirá consultarlos por su etiqueta en el resto de la declaración. Graeme Birchall's DB2 SQL Cookbook (un e-book bien mantenido y gratuito) tiene algunos buenos ejemplos de este y otros patrones avanzados de SQL. Joe Celko es otra buena fuente de ideas sobre cómo hacer que SQL haga más trabajo pesado por usted.