Cita: como ing. electrónico se bien el tipo de magnitudes que representan el voltaje, la corriente la potencia etc etc... sin embargo mi cliente no necesita hacer ninguna operación matemática con estos valores y además desea incluir en el dato ingresado el rango ya sea en mA, o A en el caso de la corriente o V o mV en el caso del voltaje la opcion clara: es varchar.
Bueno, perdona que discrepe, pero creo que eso es incorrecto. Antes de usar un VARCHAR, que resulta ineficiente, se usan dos campos, uno para definir la magnitud, y otro para indicar la unidad de medida.
Desde el punto de vista de un DBA, no tiene ningún sentido usar 100 bytes para almacenar una información que se puede almacenar con 10 (8 del valor y con toda la furia 2 para la unidad de representación).
Cita: el dato num_inv hace referencia a un número de inventario que inicialmente consideré como entero pero al estar en campo trabajando en una institución te das cuenta que los números de inventario de los equipos muebles enceres etc etc no son precisamente números sino caracteres.
Eso es una decisión de diseño que puede salir del relevamiento. Si realmente lo usan así y siempre lo han usado como codificación alfanumérica, entonces si corresponde mantenerla.
Pero si la codificación alfanumerica responde a un conjunto de códigos alfabéticos, junto con un valor numérico, supongamos "AAABBCC000000", eso son cuatro campos al normalizarlo.
AL menos desde la óptica de BBDD, porque es mucho más eficiente tener los códigos separados y agrupados luego en la PK.
La performance de la base te lo agradecerá.
Cita: y por último las longitudes de los datos no son puestas al azar sinó mas bien un estimado del valor máximo que podrían tomar en casos extremos.
OK. Entiendo.
De todos modos longitudes de datos con números enteros multiplos de 10, en BBDD implican redondeos por cota de alta, sin medir la longitud real.
Me refiero a que si un X dato se ha encontrado como máximo en 132 caracteres, ponerlo de 200 es redondear por exceso. Con 140 ó 150 alcanza. 200 son innecesarios y se pagan con costos de consulta.
La cosa, como decía mi profesor de Base de Datos I, es que la visión de ingenieros y programadores (sin desmerecer ninguna de las especialidades) es algo diferente a la forma en que el analista de datos ve los sistemas.
Cuando lo dijo creí que exageraba, pero diferentes experiencias me han confirmado su apreciación.
De allí que para mi la cosa se mire de un modo distinto, con detalles que parecen pequeñeces. Pero puedo asegurarte que cambios de ese tipo tienen un gran impacto a largo plazo.
Como sea, volviendo al problema central, ¿pudiste probar el script como te lo planteo?
Puede que aún haya que afinarlo, pero la cosa va por allí.