El plugin DataTables (V). Consumiendo datos externos.

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail

datatablesTenemos ya cierta soltura en el uso del plugin DataTables. Sin embargo, es mucho lo que aún nos queda por aprender para sacarle realmente partido a esta magnífica herramienta. En los artículos anteriores hemos estado sentando las bases de lo que se puede hacer con este plugin, pero ahora las apuestas han subido. Ya no jugamos con cerillas, sino emocionantes partidas en las ligas de campeones. En este artículo vamos a aprender a obtener los datos que queremos mostrar de una forma dinámica. Ya no estarán grabados a fuego en el código, sino que se nos generará un dataset a partir de una fuente externa, según le pidamos más y más al plugin. También aprenderemos las bases de cómo se comunica el plugin con el script secundario, en uno y otro sentido. Con lo que aprendamos en este artículo estaremos listos para pasar al siguiente nivel.

PETICIONES Y RESPUESTAS

Cuando usamos DataTables en una página, y esta se carga por primera vez, el plugin envía una petición de datos al script secundario, y este le responde con los resultados. Cada vez que cambiamos la ordenación por una columna, el plugin se vuelve a comunicar con el script secundario. Y también si usamos el paginador, o cada vez que tecleamos o borramos un carácter en la caja de búsqueda… Cuando usamos el plugin DataTables, la página está, constantemente, comunicándose con el script secundario, enviándole la petición, y recibiendo, cómo respuesta, los datos devueltos para mostrar en la página.

LAS PETICIONES

Las peticiones se hacen siempre por ajax, por el método GET, y le pasan al script secundario una gran cantidad de datos. De estos, datos hay algunos (unos pocos) que no nos resultan relevantes, por ahora al menos, pero hay otros que sí debemos conocer, porque los vamos a usar en el script secundario para obtener los resultados deseados. Estas variables que pasan por GET y que nos interesan especialmente son las siguientes:

  • iColumns. Contiene el número de columnas que tiene la tabla. El plugin DataTables identifica estas columnas a partir de las celdas que hay en la cabecera de la tabla HTML a la que se aplica dicho plugin.
  • sEcho. Es un indicador que podríamos llamar de “número de operación”. Cuando se carga la página inicialmente vale 1. Cada vez que el plugin llama al script secundario (es decir, cuando se cambia de página, se cambia el número de elementos a la vista, se cambia el orden de una columna o se teclea en la caja de búsqueda), este valor se incrementa. El script secundario lo devuelve cómo parte del JSON de respuesta y el plugin lo usa cómo checksum, para comprobar que se ha recibido el mismo valor que se envió.
  • iDisplayStart. Se usará para que el plugin determine a partir de que registro se empezará a mostrar. Por defecto, se envía el valor 0, es decir, que la primera carga de datos que se muestre en la tabla empezará desde el primer registro. Esto cambiará con la paginación. Este dato es, en todo caso, gestionado por el propio plugin.
  • iDisplayLength. Por defecto, si no especificamos otra cosa, este valor es 10, lo que indica que los resultados se mostrarán en páginas de 10 filas. Esto depende de cómo hayamos configurado la propiedad iDisplayLength que vimos en el artículo anterior.
  • sSearch. Tendrá un valor si se ha establecido algún criterio de búsqueda, es decir, si se ha tecleado algo en la caja de búsqueda de la parte superior derecha. En ese caso, el valor será el que se haya tecleado en dicha caja. En caso contrario, no tendrá valor alguno (lo que hará que se reciba cómo cadena vacía).
  • sSearch_n. Existen tantas variables como columnas tenga la tabla y n es el índice de la columna. Así, si la tabla HTML tiene cuatro columnas, la query string tendrá las variables sSearch_0, sSearch_1, sSearch_2 y sSearch_3. Por defecto estas variables van sin ningún valor. En el artículo VII de esta serie aprenderemos que podemos usarlas para buscar un valor en una columna específica, por programación.
  • bRegex_n. Existen tantas variables como columnas tenga la tabla y n es el índice de la columna. Así, si la tabla HTML tiene cuatro columnas, la query string tendrá las variables bRegex_0, bRegex_1, bRegex_2 y bRegex_3. Por defecto estas variables tienen el valor false, pero podemos usarlas para buscar una expresión regular en las distintas columnas, mediante programación.
  • bSearchable_n. Existen tantas variables como columnas tenga la tabla y n es el índice de la columna. Así, si la tabla HTML tiene cuatro columnas, la query string tendrá las variables bSearchable_0, bSearchable_1, bSearchable_2 y bSearchable_3. Por defecto estas variables tienen el valor true, lo que indica que se pueden efectuar búsquedas sobre los datos de cada columna. Si a alguna columna le añadimos, en las propiedades del plugin, 'searchable':false (cómo vimos en el artículo anterior), la correspondiente variable en la query string tendrá el valor false, lo que hará que no se pueda buscar nada en esa columna.
  • bSortable_n. Existen tantas variables como columnas tenga la tabla y n es el índice de la columna. Así, si la tabla HTML tiene cuatro columnas, la query string tendrá las variables bSortable_0, bSortable_1, bSortable_2 y bSortable_3. Por defecto estas variables tienen el valor true, lo que indica que se pueden efectuar ordenaciones sobre los datos de cada columna. Si a alguna columna le añadimos, en las propiedades del plugin, 'orderable':false (cómo vimos en el artículo anterior), la correspondiente variable en la query string tendrá el valor false, lo que hará que no se puedan ordenar las filas de la tabla usando esa columna cómo criterio.
  • iSortCol_0. Se emplea para indicar por que columna se ordenan los datos a la carga inicial de la página. Por defecto, envía el valor 0, lo que indica que, inicialmente, la tabla se ordena por la primera columna de la izquierda. Ya veremos que podemos cambiar esto por programación.
  • sSortDir_0. Se usa para indicar el criterio de ordenación inicial, enviando el valor asc (ascendente). Por programación podreemos cambiar esto a desc (desdcendente).
  • iSortingCols. Se emplea para indicar por cuantas columnas se ordena inicialmente la tabla. Por defecto, recible el valor 1, pero podemos cambiar esto por programación. Es decir. Si tenemos una tabla con datos de personas (miembros de un club, personal de una empresa, etc) podemos querer que la ordenación se produzca por dos columnas (el nombre y los apellidos, por ejemplo). En este caso, esta variable tendrá el valor 2 y, además, existirían también las variables iSort_1 y sSortDir_1.

Además hay otras variables pero, cómo hemos comentado, de momento no nos interesan.

LAS RESPUESTAS

Las respuestas siempre llegarán en formato JSON, y es el plugin quien se encargará de renderizarlas en el navegador. Se pueden configurar o modificar en el script secundario, cosa que aprenderemos a hacer en este artículo, y en otros siguientes aunque, antes, deberemos ver otras cosas. También, en artículos posteriores, aprenderemos cómo los datos de la respuesta pueden ser procesados, antes de mostrarlos, en el script principal (el que renderiza la tabla).

EL SCRIPT PRIMARIO

Para que todo esto funcione cómo debe, tenemos que configurar el srcript primario, es decir, el que monta el plugin, define la tabla, etc. En concreto, en las opciones del plugin debemos añadir:

"bServerSide": true

Además, el nombre (y, en su caso, la ruta) del script receptor no debe ir ya en la propiedad ajax, sino en una que se llame sAjaxSource.

Para crear este ejemplo vamos a usar una tabla de una base de datos MySQL con datos de personal de una empresa multinacional. En concreto, tendremos el nombre, el apellido, el cargo, la ciudad en que reside y trabaja, la fecha de ingreso y el salario bruto anual de cada miembro de la plantilla. Hemos usado una adaptación libre de la lista de personal que se usa en los ejemplos de la página de DataTables. Para poder recrear la base de datos en tu ordenador te dejo el SQL para descargar en este enlace. El script secundario recibirá una petición, buscará los datos en la base de datos, y los enviará al script primario, que los renderizará en la tabla. Esta forma de trabajar es mucho más flexible que cómo veníamos haciéndolo hasta ahora, con los datos tecleados “a fuego” en el código. En el mundo real, siempre se trabaja con datos que proceden de fuentes externas (bases de datos u otras), nunca con datos en código.

El script primario se llama articulo_05.php y su listado es el siguiente:

Cómo ves, aquí no hay grandes novedades. Aparte de los dos detalles que hemos comentado al principio de este apartado (opciones bServerSide y sAjaxSource), y del hecho de que ahora la tabla tiene seis columnas en lugar de cuatro, el script y el uso que aquí hacemos del plugin es el que ya conocemos. La enjundia de esto está en lo que vamos a ver a continuación:

EL SCRIPT SECUNDARIO

El script secundario, es decir, el que proporciona los datos al plugin para que este los renderice en el navegador, cambia ahora totalmente. Ya no es una matriz de datos fija convertida a JSON, sino que debe recibir los datos de la query string de la llamada del plugin y usarlos para configurar una consulta contra una base de datos. Esto suena a muy complejo y, desde luego, la primera vez que lo ves, impresiona un poco. En este artículo he procurado simplificar al máximo (a costa de sacrificar algunas prestaciones del plugin que dejaremos para artículos posteriores). Vamos a ver el listado completo y luego lo comentamos. Se llama datos_externos_05.php y es, nada más y nada menos, que así:

Lo primero de todo, prueba como funciona esto. Con tu phpMyAdmin create una base de datos lllamada datatables y ejecuta el SQL que te descargaste más arriba (vale, te pongo de nuevo aquí el enlace para que lo tengas a mano). Copiate los dos scripts de arriba en la ruta localhost/datatables y teclea en tu navegador localhost/datatables/articulo_05.php para que veas que todo funciona correctamente. Ahora vamos a ver cómo funciona. Sabemos que lee los datos de la tabla adecuada en la base de datos, y prepara el JSON de la respuesta, pero vamos a ver cómo lo hace.

En primer lugar, por supuesto, usamos la codificación UTF-8, así:

mb_internal_encoding ('UTF-8');

Ahora vamos a crar una conexión con la base de datos. También podríamos importarla de un script de configuración, con un include o un require, pero, en este ejemplo, cómo la conexión sólo se usa en este script, y por razones de claridad, la vamos a crear aquí. Usamos, por fiabilidad, una conexión PDO:

$conexion = new PDO('mysql:host=localhost;dbname=datatables;charset=UTF8', 'root', '');
$conexion->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

En todo caso, cómo vamos a trabajar con base de datos, está más que claro que necesitamos una conexión, y ya la tenemos. Si no conoces como funcionan en PHP las conexiones PDO a bases de datos, te interesará leer este artículo.

Lo siguiente es recuperar todos los datos de la llamada que han llegado por la query string cuando se ha creado el objeto DataTables en el script primario. Lo hacemos así:

$datosDeLlamada = $_GET;

Cuando usamos este sistema podemos recuperar datos de una tabla, o de más de una. En este ejemplo, por simplificar, estamos trabajado con una sola tabla, pero en otros posteriores veremos consultas que implicarán a dos o más tablas. En todo caso, debemos definir el nombre de la(s) tabla(s) con la(s) que trabajaremos y la forma más cómoda de hacerlo es en una matriz, así:

$tablasDeBBDD = array(
    'personal'
);

El siguiente paso requiere un poco más de atención. Debemos definir, en una matriz, las columnas de la tabla que se usarán para construir la respuesta en JSON, y debemos especificarlas en el mismo orden en que queramos mostrarlas, y que viene definido por la cabecera de la tabla HTML en el script primario. Nos referimos a las columnas de la tabla MySQL así:

$columnasParaRetorno = array(
    $tablasDeBBDD[0].'.nombre',
    $tablasDeBBDD[0].'.apellido',
    $tablasDeBBDD[0].'.cargo',
    $tablasDeBBDD[0].'.ciudad',
    $tablasDeBBDD[0].'.fecha_de_ingreso',
    $tablasDeBBDD[0].'.salario_bruto_anual'
);
$numeroDeColumnas = count($columnasParaRetorno);

En este caso, el orden de las columnas en la tabla MySQL coincide (porque lo hemos hecho así a propósito) con el orden de las cabeceras de la tabla HTML del script primario, pero, si no fuera así, respetaremos el orden marcado por esta última. Fíjate que los nombres de las columnas MySQL van precedidos del nombre de la tabla a la que corresponde cada columna. En este caso, cómo solo usamos una tabla de datos, podríamos haber omitido esa parte, pero mejor acostumbrarnos a hacer las cosas bien.

Lo siguiente que viene es un poco más delicado. Se trata de determinar si hay que buscar determinados registros, según el usuario teclee “algo” en la caja de búsqueda de la parte superior derecha. Recuerda que, cada vez que añade o quita un carácter en esa caja, el plugin va a llamar a este script secundario para hacer una búsqueda en tiempo real. Tenemos que ver si hay contenido en la caja de búsqueda. En caso de haberlo (lo que corresponde al parámetro sSearch, de la lista que vimos al principio de este artículo), se debe construir lo que luego será la condición de la consulta, buscando ese contenido en todas las columnas que estén marcadas como searchables, es decir, que no las hayamos especificado como 'searchable':false.

$reglasDeFiltradoDeUsuario = array ();
if (isset($datosDeLlamada['sSearch']) && $datosDeLlamada['sSearch'] !== "") {
    for($i = 0; $i < $numeroDeColumnas; $i++) {
        if (isset ($datosDeLlamada['bSearchable_'.$i]) && $datosDeLlamada['bSearchable_'.$i] == 'true') {
            $reglasDeFiltradoDeUsuario[] = $columnasParaRetorno[$i]." LIKE '%".addslashes($datosDeLlamada['sSearch'])."%'";
        }
    }
}
if (!empty($reglasDeFiltradoDeUsuario)){
    $reglasDeFiltradoDeUsuario = ' ('.implode(" OR ", $reglasDeFiltradoDeUsuario).') ';
} else {
    $reglasDeFiltradoDeUsuario = '';
}

Observa con detalle el fragmento de código que acabamos de reproducir. Lo primero es comprobar si hay un contenido en la caja de búsqueda (variable $datosDeLlamada['sSearch']) porque, si no lo hay (la caja está vacía), no hay que buscar nada en ninguna parte. Si hay contenido, vamos a crear un elemento de una matriz, que hemos llamado $reglasDeFiltradoDeUsuario, por cada columna que sea searchable, de forma que buque en esa columna el contenido de la caja de búsqueda mediante el operador LIKE %%. Luego, si tenemos contenido en la matriz, la convertimos en una cadena, uniendo todas las búsquedas mediante ' OR '. Así, cómo en este caso, todas las columnas son searchables, si tenemos en la caja de búsqueda, por ejemplo, york, la matriz $reglasDeFiltradoDeUsuario quedará así:

$reglasDeFiltradoDeUsuario[0] = "personal.nombre LIKE '%york%'";
$reglasDeFiltradoDeUsuario[1] = "personal.apellido LIKE '%york%'";
$reglasDeFiltradoDeUsuario[2] = "personal.cargo LIKE '%york%'";
$reglasDeFiltradoDeUsuario[3] = "personal.ciudad LIKE '%york%'";
$reglasDeFiltradoDeUsuario[4] = "personal.fecha_de_ingreso LIKE '%york%'";
$reglasDeFiltradoDeUsuario[5] = "personal.salario_bruto_anual LIKE '%york%'";

Al convertir esta matriz a una cadena mediante implode, cómo vemos en el código, quedará así:

$reglasDeFiltradoDeUsuario = "personal.nombre LIKE '%york%' OR personal.apellido LIKE '%york%' OR personal.cargo LIKE '%york%' OR personal.ciudad LIKE '%york%' OR personal.fecha_de_ingreso LIKE '%york%' OR personal.salario_bruto_anual LIKE '%york%'";

Cómo puedes ver, esto ya es una claúsula de búsqueda de una consulta MySQL, que montaremos más adelante.

Del mismo modo en que hemos creado una condición de búsqueda, debemos crear una condición de ordenación. Lo hacemnos con el siguiente código:

$reglasDeOrdenacion = array ();
if (isset($datosDeLlamada['iSortCol_0'] )) {
    $columnasDeOrdenacion = intval($datosDeLlamada['iSortingCols']);
    for($i = 0; $i < $columnasDeOrdenacion; $i ++) {
        if ($datosDeLlamada['bSortable_'.intval($datosDeLlamada['iSortCol_'.$i])] == 'true') {
            $reglasDeOrdenacion [] = $columnasParaRetorno[intval($datosDeLlamada['iSortCol_'.$i])].($datosDeLlamada['sSortDir_'.$i] === 'asc'?' asc':' desc');
        }
    }
}

if (!empty($reglasDeOrdenacion)) {
    $reglasDeOrdenacion = " ORDER BY ".implode(", ", $reglasDeOrdenacion);
} else {
    $reglasDeOrdenacion = "";
}

Cada vez que se pulse sobre la cabecera de una columna ordenable para cambiar la ordenación de los registros, el plugin efectúa una llamada al script secundario. Este determina, mediante las variables iSortCol_n, bSortable_n y sSortDir_n cual es la columna de ordenación y en que sentido se ordena. En este ejemplo, sólo estamos usando una columna de ordenación (la que sea donde pulsemos). En otros artículos veremos que se puede ordenar, programaticamente, por más de una columna. En este caso, $reglasDeOrdenacion nos quedará cómo una condición simple, del tipo:

ORDER BY personal.apellido

Lo siguiente es establecer una claúsula LIMIT, en base a las variables iDisplayLength e iDisplayStart, que son enviadas por el plugin en la query string de cada llamada, y que dependen del combo de filas por página, y del número de página, respectivamente. Lo hacemos así:

$reglaDeLimitacion = ($datosDeLlamada['iDisplayLength'] > 0)?' LIMIT '.$datosDeLlamada['iDisplayStart'].
', '.$datosDeLlamada['iDisplayLength'].';':';';

Si en la construcción del objeto DataTables hemos usado "paging": false (lo que implica que no queremos paginación, sino ver todos los registros de una sola vez, el valor de la clave iDisplayStart es -1, cosa que comprobamos al establecer la regla de limitación.

Cómo ya tenemos todas las claúsulas, los nombres de tablas y los de columnas, ya podemos crear la consulta que leerá en la base de datos y devolverá los resultados en una matriz que, en este ejemplo, he llamado $DataSet. Lo hacemos así:

$consulta = "SELECT ".implode(', ', $columnasParaRetorno)." ";
$consulta .= "FROM ".implode(', ', $tablasDeBBDD)." ";
$consulta .= "WHERE 1 ";
if ($reglasDeFiltrado > "") $consulta .= "AND (".$reglasDeFiltrado.") ";
$consulta .= $reglasDeOrdenacion;
$consulta .= $reglaDeLimitacion;
$hacerConsulta = $conexion->prepare($consulta);
$hacerConsulta->execute();
$DataSet = $hacerConsulta->fetchAll(PDO::FETCH_ASSOC);
$hacerConsulta->closeCursor();

El dataset devuelto por esta consulta ya contiene, exactamente, las filas que vamos a mostrar en la tabla.

El siguiente paso puede no ser necesario (aunque en este ejemplo sí lo es) y depende de lo que queramos obtener. Si, por ejemplo, alguno de los datos, debe sufrir alguna transformación antes de enviarlo al plugin, lo haremos aquí. En este caso tenemos dos datos que deben ser transformados. El primero es la fecha de ingreso, que procede de la base de datos en formato yyyy-mm-dd y debe mostrarse en formato dd-mm-yyyy. El segundo es el salario anual. Está cómo un número flotante con dos posiciones decimales, pero debemos darle formato de moneda y agregarle el símbolo del euro. Así pues, lo que hacemos es recorrer todo el dataset y modificar estos dos datos en cada fila, así:

foreach ($DataSet as $keyDL=>$DL){
    $DataSet[$keyDL]['fecha_de_ingreso'] = date("d-m-Y", strtotime($DL['fecha_de_ingreso']));
    $DataSet[$keyDL]['salario_bruto_anual'] = number_format($DL['salario_bruto_anual'], 2, ",", ".").' €';
}

Y contamos el número de registros del dataset, porque pueden ser los que se hayan pedido en el combo superior izquierdo, o menos, si no quedan suficientes. Lo hacemos así:

$numeroDeRegistrosDelDataSet = count($DataSet);

El siguiente paso es contar el número de registros que cumplen la condición de filtrado (que tienen alguna columna cuyo dato coincide con la caja de búsqueda), si ordenar ni limitar. Este número se devolverá luego al plugin del script primario, para la información que aparece en la parte inferior izquierda de la tabla. Lo hacemos así:

$consulta = "SELECT COUNT(".$columnasParaRetorno[0].") ";
$consulta .= "FROM ".implode(', ', $tablasDeBBDD)." ";
$consulta .= "WHERE 1 ";
if ($reglasDeFiltrado > "") $consulta .= "AND (".$reglasDeFiltrado.") ";
$hacerConsulta = $conexion->prepare($consulta);
$hacerConsulta->execute();
$totalDeRegistrosConFiltrado = $hacerConsulta->fetch(PDO::FETCH_NUM)[0];
$hacerConsulta->closeCursor();

El siguiente paso es contar el total de registros de la tabla primaria (o la única, si sólo hay una, cómo en este caso). Este dato también es necesario para la información complementaria de la parte inferior izquierda de la tabla. Lo hacemos así:

$consulta = "SELECT COUNT(".$columnasParaRetorno[0].") ";
$consulta .= "FROM ".$tablasDeBBDD[0].";";
$hacerConsulta = $conexion->prepare($consulta);
$hacerConsulta->execute();
$totalDeRegistrosEnBruto = $hacerConsulta->fetch(PDO::FETCH_NUM)[0];
$hacerConsulta->closeCursor();

Ahora, por fin, tenemos ya todos los datos necesarios para enviarle la respuesta adecuada al plugin en el script primario. Debemos disponerlos en una matriz con la estructura y las claves adecuadas. Esto lo hacemos en dos pasos. En el primero, guardamos todos los contajes que hemos leido, así como el checksum de la operación, y creamos una matriz con la clave aaData, para luego almacenar las filas del dataset. El primer paso es así:

$matrizDeSalida = array(
    "sEcho" => intval($datosDeLlamada['sEcho']),
    "iTotalRecords" => strval($totalDeRegistrosEnBruto),
    "iTotalDisplayRecords" => strval($totalDeRegistrosConFiltrado),
    "aaData" => array ()
);

Y el segundo, donde almacenamos las filas del dataset, así:

foreach ($DataSet as $DL){
    $registro = array();
    foreach ($DL as $dato) $registro[] = $dato;
    $matrizDeSalida['aaData'][] = $registro;
    unset($registro);
}

Y ya está. Convertimos la matriz a JSON, y la devolvemos por ajax al plugin, así:

$salidaDeDataSet = json_encode ($matrizDeSalida, JSON_HEX_QUOT);
echo $salidaDeDataSet;

CONCLUSIONES

Este proceso parece muy laborioso (y lo es). Sin embargo, nos da una flexibilidad y una potencia de procesamiento sin la que todo el plugin, realmente, no serviría para nada. Por otro lado, una vez que tenemos el esqueleto básico del script secundario (que es el que hemos visto en este artículo) adaptarlo a cualquier necesidad que podamos tener, con cualquier fuente de datos, es cuestión de sólo unos minutos, como veremos en el próximo post sobre DataTables. Si tienes cualquier duda, ponte en contacto conmigo, o posteala en el foro, y algún miembro de la comunidad te la resolverá.

Todo el código de este artículo (scripts y base de datos) lo tienes en este enlace.

     

5 comentarios:

  1. Excelente, gracias he revisado todos los post hasta aqui sobre datatables. Me costo un poco no perderme con lo de los arrays pero al final la cogi. TEnia una duda cuando en el WHERE hay un 1 al final porque es esto?

    • Hola. Supongo que te refieres a la consulta de selección en el script secundario. El poner WHERE 1 es para mantener la sintaxis básica de la consulta SQL. Cuando se crean las cadenas de cláusulas (las que en el script se llaman $reglasDeFiltrado, $reglasDeOrdenacion y $reglaDeLimitacion) empiezan todas con el operador AND. Si las concatenáramos a “WHERE ” sin más, podría quedar algo como “WHERE AND nombre LIKE ‘%Laura%'” (por ejemplo), lo que daría un error 1064 de sintaxis SQL. Poniendo el 1 respetas la sintaxis SQL y no altera el resultado de la consulta, porque ese 1 lo cumplen todos los registros. Por ejemplo, poner “SELECT * FROM usuarios” es lo mismo que poner “SELECT * FROM usuarios WHERE 1”, pero de esta forma, ya has escrito una cláusula inicial, de modo que encadenar las demás con AND no te da error de sintaxis.

      Espero haberte ayudado.

  2. Muchas gracias. Valoro mucho el trabajo que te tomaste. Estaré implementando algo asi en mi pagina debido a que una tabla interna de contactos tiene mas de 5.000 registros y se puso lento (MUY LENTO) usando datatables sin este plugin.
    Al final vuelvo y te comento como me fue.
    Gracias por tu trabajo!

    • Hola. Te agradezco tu comentario. Aprecio mucho que estos artículos resulten útiles a todos los usuarios. En cuanto a lo de que se “vuelva lento”, ten en cuenta una cosa. Con 5000 registros no deberías notar lentitud alguna. Yo lo he probado con tablas con más de dos millones de registros y apenas se nota latencia. La clave está en indexar adecuadamente las tablas. Si tienes una tabla con varios campos, crea un índice por cada campo que vayas a usar para búsquedas. Si, por ejemplo, tu tabla es de usuarios con nombre, dni, dirección, telefono, provincia, etc. crea un índice por cada uno de los campos en la estructura. Sy usas MySQL, desde PHPMyAdmin puedes hacerlo con mucha facilidad. Es un proceso un poco pesado, pero muy fácil, y sólo tienes que crearlos una vez. Luego ya están ahí para siempre. Eso acelera las consultas de selección de una forma brutal. 🙂

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *