Cita:
Empezado por Chris
Puede ser que ya se haya encontrado una solución, pero no es la optima realmente. No es muy buena idea que la base de datos funcione de muleta de un programador que no pudo solucionar un problema de la GUI. Agregar un campo más lo único que hará es aumentar la cantidad de datos que deben intercambiarce y para rematar, usando un procedimiento almacendado, la consulta se vuelve más lenta. Con estos dos problemas, todos tus usuarios juntos podrían perder mucho más tiempo del que no quisiste tomarte en moldear una mejor idea.
Obviamente, es decisión de Casimiro en este caso tomar un camino para su solución, pero yo sigo pensando en que es mucho mejor seguir trabajando del lado del código de la GUI en luegar de utilizar la base de datos como solución.
|
Nunca se ha dicho que sea la más óptima, que sea la mejor, o que fuese la única alternativa.
Es sólo una posibilidad más que se baraja y debo decir que en buena parte tiene su simpleza.
Quizá un SP no se tan rápido que una consulta. Quizá se pierda un poco de velocidad y perfomance cuando se tengan varios registros y sean muchos clientes quienes estén atacando el servidor pero la posibilidad de que esté el SP ayuda a que buena parte del código sea más simple.
Si el motor tiene la capacidad y los datos necesarios para ayudar a facilitar algunas operaciones del lado del cliente es más que una buena posibilidad de evaluarlo. ¿No es acaso una de las reglas que un desarrollador debe siempre considerar?
Si el servidor puede asumir esa tarea y puede darnos los datos pre-masticados que la haga.... para todo lo demás existe mastercard... este... digo el sistema cliente.
No se trata de una chapuza como lo quieres vender, ni que el programador es ineficiente o incompetente por no haber logrado algo por otra vía. Si tanto te preocupa encontrar una solución que no esté vinculada con la base de datos y sea por código yo ya había indicado una vía, que me tomo la molestia de corregir:
Disponer de una estructura, una lista, a modo del campo ficticio "Colorear" y llenar esta lista con los 1 o 0 (o el color, o lo que quieran) para que luego al momento de pintar el DBGrid pueda recuperarse este dato y saber de que color pintarlo.
El punto es que NECESARIAMENTE se debe contar con toda la información de todos los registros para saber de que color pintar. No puede verse y atacar el problema considerando el registro de forma individual, ya que su color está relacionado con su predecesor y es necesario mantener en memoria, de alguna forma, el color asignado para que a efectos de un desplazamiento podamos volver al estado original.
Saludos,