Cuando trabajáis con InterSystems IRIS, los desarrolladores y arquitectos de bases de datos a menudo se enfrentan a una decisión crítica: si usar SQL Dinámico o SQL Embebido para consultar y actualizar datos. Ambos métodos tienen sus propias fortalezas y casos de uso, pero comprender sus implicaciones en el rendimiento es esencial para tomar la decisión correcta. El tiempo de respuesta, una métrica clave en la evaluación del rendimiento de las aplicaciones, puede variar significativamente dependiendo del enfoque de SQL que utilicéis. El SQL Dinámico ofrece flexibilidad, ya que las consultas pueden construirse y ejecutarse en tiempo de ejecución, lo que lo hace ideal para escenarios con necesidades de consulta impredecibles o altamente variables. Por el contrario, el SQL Embebido enfatiza la estabilidad y eficiencia al integrar el código SQL directamente en la lógica de la aplicación, ofreciendo tiempos de respuesta optimizados para patrones de consulta predefinidos.
En este artículo, exploraré los tiempos de respuesta al usar estos dos tipos de SQL y cómo dependen de las diferentes estructuras de clases y del uso de parámetros. Para ello, voy a utilizar las siguientes clases del diagrama:
.png)
Para probar los tiempos, creé la siguiente cantidad de objetos para cada clase:
- Patient - 50M
- Visit - 150M
- Doctor - 500K
- Address - 50M
De esta manera, esperaba que vierais tiempos razonables para la ejecución de las consultas y que pudierais observar las diferencias entre ejecutar SQL Embebido y SQL Dinámico. El único índice que añadí fue el índice automático de uno a muchos para la relación Doctor-Visit.
Así que vamos a ver las consultas que voy a ejecutar y, después, la duración de su ejecución:
select count(*) from Hospital.Address select count(*) from Hospital.Address where State = :param select count(*) from Hospital.Patient p left join Hospital.Address a on p.address = a.id select count(*) from Hospital.Patient p left join Hospital.Address a on p.address = a.id where a.State = :param select count(a.Address->State) from Hospital.Patient a select count(*) from Hospital.Patient p where p.Address->State = :param select count(p.Visit->VisitDate) from Hospital.Patient p select count(*) from Hospital.Patient p where p.Visit->VisitDate > :param select count(v.Patient->Name) from Hospital.Visit v select count(*) from Hospital.Visit v where v.Patient->Name %startswith :param select count(v.Patient->Address->State) from Hospital.Visit v select count(*) from Hospital.Visit v where v.Patient->Address->State = :param select count(v.Doctor->Name) from Hospital.Visit v select count(*) from Hospital.Visit v where v.Doctor->Name %startswith :param select count(*) into :p from Hospital.Visit v where v.Doctor->Name %startswith :param and v.Patient->Name %startswith :param select count(*) into :p from Hospital.Visit v where v.Doctor->Name %startswith :param and v.Patient->Name %startswith :param and v.Patient->Address->State = :param1
Obviamente, lo anterior es la sintaxis para SQL Embebido (porque hay parámetros nombrados). Para SQL Dinámico, las consultas son casi iguales, pero en lugar de parámetros nombrados, tenéis parámetros no nombrados 😉. Por ejemplo, para la última consulta, tengo la siguiente consulta:
select count(*) from Hospital.Visit v where v.Doctor->Name %startswith ? and v.Patient->Name %startswith ? and v.Patient->Address->State = ?
Ahora, vamos a echar un vistazo a los resultados:
| No of query | Embedded SQL (sec) | Dynamic SQL (sec) |
| 1 | 49 | 12 |
| 2 | 3 | 3 |
| 3 | 32 | 26 |
| 4 | 47 | 46 |
| 5 | 48 | 46 |
| 6 | 47 | 46 |
| 7 | ||
| 8 | ||
| 9 | 31 | 26 |
| 10 | 83 | 81 |
| 11 | 41 | 45 |
| 12 | 73 | 71 |
| 13 | 23 | 26 |
| 14 | 1 | 1 |
| 15 | 2 | 2 |
| 16 | 3 | 3 |
Podéis ver un gran valor atípico, que es la primera consulta. El SQL Embebido tardó mucho más tiempo en ejecutarse que el SQL Dinámico. Ejecutando las mismas consultas varias veces obtuve más o menos el mismo resultado. Así que es lo que es.
En general, podéis ver que la relación padre-hijos es mucho más lenta desde el lado de la propiedad de los hijos, aunque todos los datos de Patient y Visit estén almacenados en el global de Patient. El índice salvó la situación para la relación de uno a muchos, y el tiempo de ejecución fue considerablemente más corto. En conjunto, el tiempo de respuesta es mayormente similar y difiere en menos del 10%; a veces, incluso es el mismo. Por supuesto, utilicé consultas simples que no tardaron demasiado en prepararse, así que esta etapa casi podría ser ignorada.
.jpg)
.png)
.png)