Sip, armar SQL con la especificacion completa es practicamente re-implementar un Parser de SQL. Sin embargo, el caso de los where es relativamente simple.
Uno de los ORMS que hice (obj-c) lo muestra:
https://bitbucket.org/elmalabarista/...e-view-default
Código PHP:
+(NSString *) buildFilterCriteria: (NSArray *)filterList {
NSMutableString * sql = [NSMutableString string];
int count;
int i;
[sql appendString :@" WHERE "];
count = [filterList count];
for (i = 0; i < count; i++) {
if (i + 1 == count) {
[sql appendFormat:@"(%@)", [filterList objectAtIndex:i] ];
}
else {
[sql appendFormat:@"(%@) AND ", [filterList objectAtIndex:i] ];
}
}
return sql;
}
+(NSString *) buildSelect: (NSString *)tableName fields:(NSArray *)fields filters:(NSArray *)filterList orders:(NSArray *)orderList {
...
...
//Add the filters
if (filterList) {
[sql appendString: [SqlGenerator buildFilterCriteria:filterList]];
}
---
OFF-TOPIC:
Ahora estoy en la tarea (por hobby) de hacer un lenguaje de programacion relacional, donde es normal programar estilo LINQ, asi que tengo por ejemplo esto:
Código SQL
[-]
data = [1, 3, 4, 2, 8, 1]
q1a = where data ? this < 4 end
q1b = where data ? this > 0 end
q1 = q1a && q1b
q2 = select data ? this * 2 end
qFinal = orderby q1 && q2 ? this end
for row in qFinal do
row | print
end
La idea es que es redudante hacer "SELECT campo1, ..." en el caso de
Código SQL
[-]where data ? this < 4 end
, y como el lenguaje es relacional, puede hacer composicion de querys (unir q1 & q2 que combina la projeccion y el filtro y luego aplica el orden)
Para que quede claro."where data ? this < 4 end" no requiere decirle "select" ni "from" porque es redundante con lo que ya se. Esa es una de las cosas que le falto al SQL para hacerlo mas amigable.
Esto no es usando una base de datos relacional, todo es en memoria. Pasarlo a SQL es algo extra que se resuelve mucho mas facil si en vez de hacer concatenacion de STRINGs genero un
AST y un mini-interprete de eso para armar los SQL.