Consejo o ayuda sobre 50.000 articulos y menu

[Highlander]

Buenas estoy realizando una aplicación de inventario y llegue a una parte en cual estoy con duda sobre como proseguir, tengo una tabla con 50.000 articulos y nesecito hacer un menu donde se puedan ir seleccionando uno o mas de estos. Normalmente haria un menu tipo listado que consulte la BD pero en este caso lo probe y demora sobre 25 sec.

Asi que alguien que le halla pasado ya algo de este tipo puede aportar con algun consejo por favor?

Estoy usando Wampserver ultima version, la tabla de 50.000 registro fue importada de excel, tiene un ID, codigo articulo, valor, descripcion, stock.

[Carxl]

Hola Highlander (jamás pensé hablar contigo xD xD A manera de broma )

Bueno, asumo que la base es la misma como si fuera un catálogo de producto... Podrías antes de cargar toda esa cantidad de registros, hacer una interfaz para que el usuario seleccionara previamente la categoría a la que pertenece el producto. Me entiendes??

La idea es que seleccione primero la categoría y dependiendo de eso cargar los productos, con eso ganarás un poco de tiempo. Lo mas probable, para esa cantidad de registros es utilizar índices.

Saludos

[Keysher]

No entiendo la problemática. ¿Tarda mucho en hacer la consulta? ¿En mostrar los datos?

¿quieres que estén todos en la misma página?

Puedes paginar los resultados para hacerlo más accesible. Pero si te interesa que los 50.000 registros se vean en la misma página.... tendrás que esperar a que se haga la consulta y luego mostrar los datos (en el bucle de mostrar puedes forzar a "escupir" el HTML al navegador con flush()).

[Highlander]

Ok en orden de respuestas:

Carxl: No hay categorias y consulte la posibilidad de crearlas y fue negativo (Hubiese sido ideal)

Keysher: El problema es que de alguna manera nesecito hacer que el usuario seleccione los articulos que desea cotizar, normalmente lo hacia asi:

Código:

<?php 
$link=conectar();
$consulta = "SELECT ID_ART, CODIGO_ART, DESC_ART FROM articulo WHERE ESTADO_ART='1' ORDER BY DESC_ART"; 
$resultado = mysql_query($consulta,$link); 
?>
            
<select name="id_art" class="style3"  id="id_art">
<option value="" selected="selected">Seleccionar</option>

<?php
while($datos = mysql_fetch_array($resultado)){
?>
<option value="<?php echo $datos["ID_ART"] ?>"><?php echo $datos["DESC_ART"] ?>&nbsp;&nbsp;[<?php echo $datos["CODIGO_ART"] ?>]</option>
<?php
}
mysql_close($link);
?>
</select>

Pero con esta cantidad de articulos se demora 25 sec en generarse.

He estado optimizando de la consulta, cambie de innodb a mysam, elimine el order by y quedo en 10 sec, talvez si pudiese tener la tabla ya ordernada podria dejarlo asi.

[Ronruby]

Wow, un select de 50,000 registros? Es un poquito tedioso para el usuario. Yo personalmente cierro la pagina :P.

Carxl: No hay categorias y consulte la posibilidad de crearlas y fue negativo (Hubiese sido ideal)

Bueno, entonces sino puedes por categorias, creo que podrias en vez de categorias, ordenarlo por la 1era letra en orden alfabetico.

Articulos que empiezen por: A, B, C, etc ...

[Highlander]

Iniciado por Ronruby

Wow, un select de 50,000 registros? Es un poquito tedioso para el usuario. Yo personalmente cierro la pagina :P.



Bueno, entonces sino puedes por categorias, creo que podrias en vez de categorias, ordenarlo por la 1era letra en orden alfabetico.

Articulos que empiezen por: A, B, C, etc ...

Claro en este caso el usuario es un empleado que generara la cotización, nunca podria presentar algo asi a un usuario comun, ahora sobre ordenar efectivamente tiene que ir por el nombre del articulo alfabeticamente, ahora estoy viendo como guardar la tabla ya ordernada en la BD para no tener que usar un ORDER BY que demora mas la consulta.

Cualquier sugerencia es apreciada por favor.

[Carxl]

Lo que pasa es que un order by es de esas intrucciones que para esa cantidad de registro prefieres evitar...

Order by, debido a su naturaleza, hará que tu Query sea mas lento

Mira, si la verdad no tienes mucha "libertad" para programar y optimizar tu aplicación, pues muéstrale al/los usuario(s) lo que pasará al ser tan restrictivos.

Soluciones hay, pero que no puedas implementarlas... nada que hacer

Saludos

[Highlander]

Iniciado por Carxl

Lo que pasa es que un order by es de esas intrucciones que para esa cantidad de registro prefieres evitar...

Order by, debido a su naturaleza, hará que tu Query sea mas lento

Mira, si la verdad no tienes mucha "libertad" para programar y optimizar tu aplicación, pues muéstrale al/los usuario(s) lo que pasará al ser tan restrictivos.

Soluciones hay, pero que no puedas implementarlas... nada que hacer

Saludos

Entiendo, entre tanto logre almacenar la BD ya ordenada alfabeticamente asi no uso order by y demora 10sec en cargar el listado.

Como solucionarias tu esto si se puede saber por favor, talvez pueda sugerirlo.

[Carxl]

Hola de nuevo Highlander

Pues como te dije en mi primer post de esta conversación, creando categorías, para dividir los productos en "secciones".

Con eso, ganas velocidad, normalización y te quedará mas fácil el manejo de los mismos. Mas que problema de programación, es problema de diseño de DB. Todo producto, dentro de un contexto de sistema pertenece a una categoría, subcategorías, líneas...

Cuando hayas hecho esto, entra a jugar con índices de mysql.

Ahora, en la programación, tendrías que hacer una interfaz para crear las "categorias", y tendrías que agregarla en la carga/modificación del producto (pues para que exista la relación, será un trabajo arduo, no por lo complejo sino por la cantidad de registros que tiene la DB, a cada uno le tendrías que asignar su respectiva categoría).

Usa analyze de mysql para que veas como se comportarán tus query, si utlizarán o no los índices que les digas, también los podrías forzar...

Es un trabajo interesante...

Saludos

[Highlander]

Ok completamente de acuerdo, el problema es que para ellos su lista de precio en excel es una bd XD

Bueno con esto yo creo que queda cerrado este caso, gracias.