Cita: Sobre los problemas con tus consultas
.. mm Tu indexas tus campos que usas para tus consultas
tipo ORDER BY .. o WHERE .. por porner algunos ejemplos? ...
sí, uso de 2 a 3 índices por tabla... doy prioridad a WHERE y JOIN por sobre ORDER, porque justo por ahi el ORDER puede ser cualquiera de los campos (justo para ese caso de sitio en particular; no en general)....pero sí los indices te sirven mucho para los order by... de todas maneras eso del array_multisort era una posibilidad, no tengo mucha idea de cómo sería y si realmente serviría...
Cita: Por lo demas .. en lo personal .. me gustan las capas
de abstracción de Base de datos que hagan ese trabajo sólo.
Temas como el de páginado .. prefiero otra classe por separado
que tal vez la pueda adjuntar a la classe Base con
algun "extended" por ejemplo a modo de "módulos" ..
Pero esto no es más que una opinión personal.
me olvidaba con respecto a la clase, hay dos opciones para usar, por ej.
Código PHP:
$obj = new Consulta;
$rs = $obj->consultar ( 'STANDALONE', 'clausula sql bla bla bla' );
en este caso no se haría nada de paginación; pero también se puede usar de otra forma para agregarle paginacion:
Código PHP:
$rs = $obj->consultar (
'campos',
'tablas',
'campo de ordenamiento DESC|ASC',
'condicionales: WHERE {campo1} = campo2,
o sino JOIN bla bla',
0,
20,
'prefijo de global "mivar_" [opcional]' );
no encontré hasta ahora forma más compacta, pero para el argumento de los condicionales WHERE o JOIN (el 4º): al nombre de campo que vaya entre { y } ése se utiliza para contar el total de registros -con una consulta COUNT() adicional, que en realidad tengo pensada sacarla y agregarle un COUNT() a la consulta principal-, si no fuera entre '{' y '}' no se cuentan los totales.
los 4 primeros argumentos son los que componen la consulta sql completa (tal vez se podrían meter en un arg. solo). los tres últimos (el último de esos 3 es opcional) se usan para hacer la paginación.
en el caso de la llamada de arriba, 0 (en el 5º argumento) sería el puntero de result-set. 20 (en el 6º) sería el número de registros a tomar de vez en vez. o sea que serían los 20 primeros registros (limit 0, 20). si fuesen 1 y 20, en lugar de 0 y 20, serían los segundos 20 registros, del 21 al 40 (limit 20, 20). el último argumento sería para crear cuatro globales con el prefijo indicado ahí; por ejemplo 'mivar_', crearía 4 vars: $mivar_inicio (1), $mivar_medio (20), $mivar_fin (supongamos 245, el total de registros), y $mivar_indices (en este caso sería: 13, o sea 13 páginas de result-sets si se usa de 20 en 20... 245 / 20 redondeado para arriba) la idea después es poner en sesión $mivar_fin para no volver a realizar COUNT() para obtener los totales de vuelta; eso todavía no lo hice
cluster, muchas gracias por tus comentarios... la verdad que me son de mucha utilidad y como siempre uno se entera de nuevas cosas
saludos