Hacer mascaras en consultas sql.

[cuburu]

Empezado por el_barto

store procedure perfect ¡¡¡¡ lo probe mas no lo implemente en mi reporte dado que como lo explique anteriormente es muy facil desde crystal reports, y como dice roman para que complicarce si existen maneras mas sencillas para solucionar mi caso, claro, un store procedure podria ser mas optimo para otros casos

Pues yo pienso que si puedes dejar todo el trabajo pesado a la BD y programas lo minimo indispensable es mejor.

Cuando manejas esta clase de condiciones por medio de Store Procedures, Views o cualquer caso y que la BD puede hacerlo, es mejor dejarselo a ella.

La respuesta que doy es muy simple.

Qué pasaria si de repente te dicen que necesita hacerse una reestructuración de todo el programa o se necesita hacer otra aplicación en un lenguaje diferente para trabajar los mismos datos en la misma BD. Pues ya no tendrías que volver a codificar este tipo de operaciones en la otra aplicación pues ya las tienes dentro de la misma BD. Solo tendrías que llamarlas.

Ademas, cuando se trabaja con grandes volumenes de información, es mejor dejar todo el asunto de integridad referencial, updates, commits, rollbacks y todas esas cosas a la BD y no tratar de controlarlas desde nuestra aplicación..... despues de todo, para que un negocio funcione cada quien debe de hacer su trabajo, y si la BD nos puede ahorrar dolores de cabeza tratando de contener posibles errores en la BD pues hagamoslo.

[roman]

Empezado por cuburu

Pues yo pienso que si puedes dejar todo el trabajo pesado a la BD y programas lo minimo indispensable es mejor.

Al César lo que es del César...

Trabajo pesado habrá de ambos lados, aplicación y servidor.

Empezado por cuburu

Cuando manejas esta clase de condiciones por medio de Store Procedures, Views o cualquer caso y que la BD puede hacerlo, es mejor dejarselo a ella.

No sé si una UDF pueda considerarse parte del servidor, pero en el caso de MySql, las funciones mencionadas sí que lo son.

Empezado por cuburu

Qué pasaria si de repente te dicen que necesita hacerse una reestructuración de todo el programa o se necesita hacer otra aplicación en un lenguaje diferente para trabajar los mismos datos en la misma BD. Pues ya no tendrías que volver a codificar este tipo de operaciones en la otra aplicación pues ya las tienes dentro de la misma BD. Solo tendrías que llamarlas.

De acuerdo. Pero toma en cuenta que no todas las aplicaciones son susceptibles de cambios tan drásticos y hay que tener cuidado con "¿qué pasa si...?" pues puede uno terminar complicandose la vida por una supuesta futura necesidad. Trabajo en un sistema hecho sobre MySql, y ha funcionado bien durante más de tres años. Y aún cuando he pensado en la posibilidad de migrar a FireBird, mientras no lo haga, me siento cómodo con él y todas las funciones predefinidas que incluye; no las cambiaría en aras de una estandarización o hipotéticos reajustes futuros.

// Saludos

[cuburu]

En eso tienes toda la razón. Es incoherente tratar de controlar algo que no sabes si se va apresentar o no.

Quizas el error mio fue darle un enfoque basado en experiencia propia. Por lo regular trabajo con sistemas de esta indole y es más sencillo realizar este tipo de "maniobras".