10 respuestas en este tema

[maurixio5540]

Buenos dias, amigos del foro

Espero me puedan colaborar.

Resulta que tengo un campo en Base de datos de tipo varchar(250) en el cual guardo registros tales como:

Normal
20
35.2
Anormal
10

u otras definiciones textuales, depende de lo que ingresen en dicho campo ya que se captura desde una caja de texto.

El inconveniente que tengo es que implemente un procedimiento en firebird donde consulto los registros en el campo mencionado, pero a su vez debo validar si el resultado en cada registro esta en un rango de numeros, es decir solo aplicaria cuando son resultados numericos. Pero como pueden ver el usuario tambien puede ingresar texto.

Existe la posibilidad de extraer mediante sql solo los registros de tipo numerico???

Este es el sql. inicial sobre el cual evaluo si esta en un determinado rango:

SELECT FIRST(1) DATOS.CAMPO
     FROM DATOS
     ORDER BY DATOS.ID DESC
     INTO
     :RESULTADO;
     IF ((RESULTADO<5)OR(RESULTADO>20)OR(RESULTADO IS NULL))THEN
        RESULTADO='999'; 

LA IDEA ES QUE SI TAMBIEN VIENE UNA PALABRA DIFERENTE A UN NUMERO LE ASIGNE EL VALOR '999'.

AGRADEZCO CUALQUIER COMENTARIO O SOLUCION AL RESPECTO

[Delphius]

Ummm,
Tengo una pregunta: ¿Términos como normal o anormal tienen algún equivalente numérico? No necesariamente un número fijo, pero un rango aceptable por el cual se pueda decir que es normal, y que es anormal.

Esto te lo digo por que yo lo haría fácil:
Hago que dicho campo sea si o si de tipo numérico (entero o real ya debes ver tu) y disponer de un campo llamado Observaciones en donde si desea el usuario pueda indicar si el valor ingresado puede ser catalogado como normal, anormal o cualquier otra obervación que desee.

Una regla de diseño es que si en un campo con el que se va a estar operando, entonces debe establecerse adecuadamente el tipo con el que se va estar usando. ¡Las mezclas son malas!

Saludos,

[maurixio5540]

Delphius, muchas gracias por responder...

Tienes razón en cuanto a lo que sugieres, pero en este caso sucede algo muy particular, y dificilmente puedo cambiar la estructura de BD asi mismo como la manera en q se captura dicha información, ya que son demasiados datos que se estan procesando y la necesidad de evaluar solo los numericos me llevo a realizar la pregunta.

Agradezco de antemano cualquier otra sugerencia al respecto.

[Wilson]

Prueba usando la función SUBSTRING de Firebird, te voy a poner un ejemplo, supongamos que la tabla llama "TABLA_PALABRAS" y tiene los campos "ID"  y "PALABRA".

SELECT PALABRA_NORMALIZDA
FROM(SELECT
IIF (SUBSTRING(TABLA_PALABRAS.PALABRA FROM 1 FOR 1) IN
('0','1','2','3','4','5','6','7','8','9'),
TABLA_PALABRAS.PALABRA, '999') AS PALABRA_NORMALIZDA
FROM TABLA_PALABRAS ORDER BY TABLA_PALABRAS.ID)

La anterior consulta  evalúa si el campo "PALABRA" comienza con un número, si es verdadero entonces toma el valor del campo, de lo contrario asigna "999".

Te coloco a continuación el script de la tabla de prueba para que evites confusiones con el alias "PALABRA_NORMALIZADA".
La he probado y funciona  correctamente.

CREATE TABLE TABLA_PALABRAS (
    ID       INTEGER NOT NULL,
    PALABRA  VARCHAR(50) NOT NULL
);

Saludos.

[cadetill]

Si puede darse el caso de que te introduzcan "4DDD" con lo que invalidaría la solución de Wilson, lo único que veo que te queda es:

1.- Hacerte una UDF que controle si el dato que hay es numérico (en Delphi hacer eso es muy sencillo, y hacer una UDF no es nada complicado)

2.- Hacer algún procedimiento almacenado que controle si todos los caracteres del campo son numéricos y que devuelva 0 o 1 según sea el caso (solución también bastante sencilla).

Si te decides por cualquiera de las dos, puedo darte alguna ayuda en ambos casos

Saludos

[Sergio]

Pues te va a costar mucho hacer lo que quieres, piensa en estos "textos" a ver como deduces que son numericos, incluso mirando tienes dudas:

12.5
12.456.123
12E-3
12,456.345
.234
0000.001
12.30$

Yo esto lo hago por programa y es muy dificil cubrir todos los casos, siempre hay cosas que se escapan.

[Delphius]

Delphius, muchas gracias por responder...

Tienes razón en cuanto a lo que sugieres, pero en este caso sucede algo muy particular, y dificilmente puedo cambiar la estructura de BD asi mismo como la manera en q se captura dicha información, ya que son demasiados datos que se estan procesando y la necesidad de evaluar solo los numericos me llevo a realizar la pregunta.

Agradezco de antemano cualquier otra sugerencia al respecto.

Pues lamento informarte de que justamente cuando el usuario puede meter lo que sea y esperar que el motor de base de datos la procese en un campo de mucha importancia cuando se espera cierto tipo es un error de diseño.

Y lamentablemente hay ocasiones en que se deben tomar decisiones que nos llevan a hacer varios cambios que afecten al sistema. Pero es mejor que lo hagas ahora y no más tarde cuando ya no solo debas ir a por controlar si hay un numero sino que te pidan otra y otra y otra más.

Aunque mi propuesta te suene a demasiado trabajo en realidad es justamente un gran ahorro. No tiene nada de complicado añadir un campo más a la tabla. Tu problema justamente no es de base de datos, sino de operatoria y diseño. En realidad el problema no es añadir un campo.... es que cuando lo añadas deberás buscar algo en términos numéricos que represente a todo lo que es "normal" y "no normal". Y como aparentemente no tienes otra información con la cual la puedas deducir del contexto, estás en dificultades en como o que llenar.

No es que las tenga contigo, es que lo que pretendes no es bueno en absoluto. Deberás llevar demasiados controles, como los que están comentando los compañeros. La mejor alternativa sería que el sistema controle esto y no el motor. Es decir que tu aplicación debiera de detectar que se está llenando y justamente el motor recibir el dato en forma limpia para que se le facilite la operatoria. De otro modo se está traslandando una responsabilidad de la aplicación al contexto de la base de datos y encima degradando el rendimiento del mismo.

Por otro lado ¿De cuantos datos estamos hablando? ¿Para un mismo campo? ¿Cómo de complejo es la recolección de los mismos? Te invito a que nos des más luz sobre tu caso. Es posible que encontremos alternativas y propuestas a que se facilite la operatoria en general, y que eso conduzca a que justamente se elimine el problema que tienes.

Saludos,

[Rolphy Reyes]

Saludos.

La sentencia Similar puede ayudarte; solo debes de aprender a usar las expresiones regulares.

[maurixio5540]

Delphius, Wilson, cadetill, Sergio y Rolphy Reyes. Muchas gracias por sus opiniones y sugerencias al respecto, en este momento voy a tratar de implementar la solución utilizando la sentencia "Similar to". Una vez terminado les contare como me fué ...

"Este foro es genial..."

[TiammatMX]

¿Y por qué no pensar al revés? Me refiero, tener en tu forma un TComboBox que tenga los valores alfanuméricos, y en tu tabla guardar solamente los valores numéricos que apuntan a una determinada palabra o palabras dentro de otra tabla que es la que utilizar para alimentar al TCombobox.

Mismo caso sería si utlizaras valores "hard code"; y así te evitarías el usar algoritmos complicados, complerjos e imprácticos...

[Delphius]

¿Y por qué no pensar al revés? Me refiero, tener en tu forma un TComboBox que tenga los valores alfanuméricos, y en tu tabla guardar solamente los valores numéricos que apuntan a una determinada palabra o palabras dentro de otra tabla que es la que utilizar para alimentar al TCombobox.

Mismo caso sería si utlizaras valores "hard code"; y así te evitarías el usar algoritmos complicados, complerjos e imprácticos...

El asunto es que al parecer la entrada de datos debe ser libre. De allí que al menos en lo que es información alfabética (o no numérica) se podría esperar un universo bastante difuso.
En lo que es número dentro de todo se puede controlar en un rango de valores de forma más fácil.

Por todo esto es que yo sugiero justamente que se tenga el campo numérico y en caso de querer añadir alguna información adicional al respecto que se disponga de un campo BLOB o VARCHAR a modo de detalles. Es lo menos doloroso.
Y si resulta que ya hay información en la base de datos, pues no va a quedar otra que tomarse el debido tiempo de hacer el data entry y revisar registro a registro que información numérica corresponderle a cada valor cualitativo.

A veces hay que hacer trabajo duro para hacer menos trabajo. 

Saludos,

Saludos,