Wikipedia:

Un consultor (del latín consultus que significa “asesoramiento”) es un profesional que provee de consejo experto en un dominio particular o área de experiencia, sea contabilidad, tecnología, ley, recursos humanos, ventas, medicina, finanzas, relaciones públicas, comunicación u otros.

La principal función de un Consultor es asesorar en las cuestiones sobre las que tienen un conocimiento especializado. Los consultores también poseen una especialización dentro de su actividad, ejemplo de esto es un Consultor contable, con un nivel de especialización mayor en los aspectos relacionados con la contabilidad o economía en una empresa a diferencia de un consultor comercial, que a veces pueden poseer un conocimiento general pero no necesariamente profundo en algunas áreas.

A ver qué opinais vosotros, pero a mi me parece muy fuerte, que un consultor externo, con su carrera de informática, tenga vacíos de conocimientos tan enormes como lo que os voy a contar. Estoy trabajando desde julio en una empresa que maneja un ERP y constantemente necesita contratar consultores externos para pequeños desarrollos en él. Este mes estoy haciendo una adaptación con el consultor del mes, desde cero, para que me vaya enseñando truquitos y vayamos más rápido.

Pues ayer teníamos un problema para hacer unas consultas. Nos salían registros repetidos y desordenados, y la solución a la que llegamos, debido a que yo de bases de datos no tengo ni puta idea (el profesor me aprobó Ficheros y bases de datos vamos), fue llevar un array con los elementos nuevos, y cada vez que lo encontraba, es que era repetido y no se mandaba a imprimir. A todo esto, no sabía poner parámetros a las funciones que hubo que declarar.

El problema más gordo surgió cuando teníamos una tabla con un índice de 5 campos. No se puede meter todo en un array. No es posible que esto no le haya sucedido a alguien antes, tiene que haber una solución mucho más sencilla. Bueno, pues dándole vueltas y más vueltas digo “¿y si usamos un group by?”. Pensaba que así se juntarían todos los registros iguales y se mostraría uno solo. Le pareció bien, pero no funcionaba porque solo los agrupaba, no quitaba los repetidos. Encima, el group by te obliga a cambiar los campos que seleccionas para que sean los mismos, así que esto nos obligaba a hacer otra select dentro, algo que se me quedó grabado que debe evitarse siempre. Seguimos dándole vueltas y desesperada entro en la wikipedia y doy con un tutorial de sql. ¡Ajá! Distinct. Eso te quita los registros repetidos. Miramos, probamos, y resulta que el ERP no puede usar distinct, eso no existe.

Con esa solución, volvemos a lo de la variable. Y funciona, pero en cuanto le metes una consulta grande, peta porque tenemos dos selects y con la primera eran unos 70.000 registros. Quedaba claro entonces que no podían hacerse dos select, y que el group by no podíamos aplicarlo. Por fin, le digo, oño, ¿por qué no ordenamos por el índice? así los repetidos nos salen juntos, como hace el group by. Funcionó, y con añadirle lo de la variable ya nos vale para cualquier consulta.

Nos llevó todo esto, exactamente, 8 horas. Tengo horario de 8 a 3, pero salí a las 7 (ya me han enseñado que en informática, sabes a qué hora entras pero no a qué hora sales). No hago más que darle vueltas sobre en qué estará especializado y cómo es posible que no se le ocurriese a él lo del group by, qué está titulado hombre, que la que lleva mes y medio aprendiendo cómo funciona un ERP soy yo. Es un tío majísimo, me gusta trabajar con él y estoy aprendiendo un huevo, pero es que entre esto y alguna experiencia anterior, me jode que sea yo la que le saque las castañas del fuego y que gastemos tantas horas en una chorrada que hubiese podido solucionarse si estuviese un poco más capacitado.

Que me den un manual que me hago consultora externa yo también. Debe cobrarse una pasta.

Powered by ScribeFire.