Eliminar Registros Repetidos con SQL
Para los que han manejado Bases de Datos y que han tenido el problema de contar con registros repetidos cuando no deberia haberlos, aqui les dejo este query:
DELETE
FROM Tabla
WHERE Tabla.idTabla IN (
SELECT MAX(idTabla)
FROM idTabla
GROUP BY Campo1, Campo2, Campo3
HAVING COUNT(*) > 1)
Este query te elimina los registros que coincidan con el resultado del subquery. Lo que hace el subquery es que busca y devuelve una lista de identificadores de los registros repetidos en base al GROUP BY; entonces tienes que reemplazar Campo1, Campo2, y Campo3, por los campos que determinan el por que están repetidos los registros, y listo, ya no deberían existir registros repetidos.
Cabe mencionar que en un buen diseño de Bases de Datos no debería existir ningún registro repetido, así que si tienen este problema, será mejor que revisen la estructura y diseño de la Base de Datos para que encuentren una solución permanente y no comprometan la calidad del software producto.
¡Feliz Día Pi!
Hoy es el día Pi (3/14), que en si, no es una festividad reconocida en México, pero a algunas personas nos agradan este tipo de coincidencias. Si bien, todos tenemos conocimiento y hemos utilizado Pi solo algunas personas le encuentran verdadera utilidad a este numero, yo lo utilice cuando hacia animaciones y juegos flash, de ahí en mas no lo he usado más.
En fin, aquí esta una sencilla animación que resume muy bien Pi:

En una nota aparte, disculpen la falta de entradas, ultimamente he estado algo ocupado con un nuevo proyecto que, aunque las cosas se fueron dando apresuradas, le estoy echando todas las ganas para que todo salga de la mejor manera. Otro día les platicare con mas detalle. Saludos.
Las AFORES (Administración de Fondos para el Retiro)
Esta entrada solo es para platicarles de las AFORES, tengo 23 años y no he pensado lo que haré cuando tenga mis 50 – 60 años, y estoy casi seguro que muchos de ustedes tampoco lo han hecho. Ahora, buscando en google, encontré que la CONSAR realiza un cuadro comparativo con los rendimientos, comisiones y rendimientos netos. Aquí les dejo un resumen:
| AFORE | Rendimiento | Comisión | Neto |
| ING | 8.06% | 1.61% | 6.45% |
| Azteca | 6.92% | 1.96% | 4.96% |
| Invercap | 4.97% | 1.73% | 3.24% |
Los datos de la tabla son del cierre de enero del 2010. Hay otras afores, pero tome estas como ejemplo.
En la tabla se ve que ING te da los mejores rendimientos. De cada $1000 que tienes en tu AFORE, ING te da $80.6 y te cobra $16.1 que te deja con $64.5 pesos. Ahora, con los mismos $1000, Azteca te da $69.2, te cobra $17.3 y te deja con $49.6 pesos y por ultimo, Invercap te da $49.7, te cobra $17.3 y te deja $32.4.
Es importante escoger la mejor AFORE desde el principio, $30 pesos de diferencia no parece mucho, pero si comienzas con una afore como Azteca o Invercap y se te olvida cambiar con el tiempo esos $32 pesos pueden llegar a ser varios miles de pesos.
De todos modos tal vez no lleguemos a viejos, pero no esta demás tener un guardadito. Saludos y RT.
Las Prioridades de los Requerimientos de Usuario
Para que cualquier proyecto resulte exitoso, se tienen que tener a todos los requerimientos y prioridades en orden. Si a todos los requerimientos se les da una prioridad alta, el proyecto no tendrá la flexibilidad necesaria para hacer lo que tiene que hacer. Si a los requerimientos no se le asigna la prioridad correcta, el sistema resultara en un fracaso, por que no podrá satisfacer las necesidades de los clientes y no será de su agrado.
La priorización de los requerimientos no es un procedimiento sencillo; todas las partes involucradas deben de ceder a algunas de las demandas para garantizar la calidad del producto.
Para darle una prioridad a cada requerimiento es mejor utilizar un método que de mas significado ó un mejor propósito al requerimiento. El usar números suena razonable, pero muchas veces nos podemos confundir con lo que significa cada numero y otras veces vamos a terminar con todos los requerimientos siendo #1.
Ahora, una manera de priorizar, es utilizando la técnica MoSCoW; está técnica nos da la facilidad de asignar prioridades de acuerdo al siguiente acrónimo:
- Must, debe de tener esta característica.
- Should, debería de tener esta característica.
- Could, podría tener esta característica.
- Won’t, no por lo pronto, pero si en el futuro.
En fin, esto método nos ayuda a lograr una mejor priorización y no complica nuestro trabajo. El acrónimo, MoSCoW, está en ingles, pero se pueden crear otros acrónimos para otros idiomas, si tienen alguna sugerencia la pueden dejar en los comentarios.
¿Qué son los Requerimientos de Usuario?
Cuando estaba en la escuela y tenia que hacer algún desarrollo de software los profesores siempre pedían todo el ciclo de vida del proyecto, pero cuando nos enseñaron las etapas del ciclo de vida, los Requerimientos de Usuario siempre era una descripcion como:
“Esto se le pregunta al cliente, es lo que quieren que haga el sistema.“
Una descripción como esta es perfecta para que los requerimientos de usuario estuvieran mal, y por lo tanto que el sistema no fuera del agrado del cliente y que los “arreglos” duraran mas que el propio desarrollo. Por eso, aquí les dejo una mejor aproximación a los requerimientos:
“Los requerimientos especifican que es lo que se quiere de un sistema para que de una mejor y mayor ventaja competitiva para el cliente.“
Los requerimientos de usuario se dividen en funcionales y no funcionales. Los requerimientos funcionales son las acciones con los que debe cumplir el sistema, deben de especificar QUE se va a hacer y no COMO se tiene que hacer. Los requerimientos no funcionales son las restricciones que limitan el numero de propuestas que cumplen con los requisitos funcionales para el desarrollo del proyecto.
Por ultimo, para elegir la mejor opción que cumpla con los requerimientos de usuarios, existe lo que son los Objetivos de Diseño, estos nos ayudan determinar que solución es la más apropiada desde el punto de vista del usuario; en los objetivos de diseño, el cliente nos dice que característica es más importante para él, si no dijera nada, nosotros podríamos desarrollar el proyecto como a nosotros nos parezca (mejorando la rapidez de respuesta del sistema, por ejemplo), pero el cliente es el único que conoce lo que realmente quiere o necesita (como el registro de nuevos clientes) ocasionando que el cliente no este satisfecho con el producto.
No tengo mucha experiencia en este tema, pero si tienen alguna pregunta o duda la platicamos en los comentarios y ya veremos a que definición llegamos. Espero haberles aclarado un poco este tema, saludos.